Roy Lyseng wrote:
> Evgeny Potemkin wrote:
>> Answers are inline.
>> Regards, Evgen.
>> Sergei Golubchik wrote:
>>> Hi, Evgeny!
>>> On Oct 08, Evgeny Potemkin wrote:
>>>> 3147 Evgeny Potemkin 2009-10-08
>>>> Bug#34384: Slow down on constant conversion.
>>>> When values of different types are compared they're converted to
>>>> a type that allows correct comparison. This conversion is done
>>>> for each comparison and takes some time. When a constant is
>>>> being compared it's possible to cache the value after conversion
>>>> to speedup comparison.
>>> On IRC you told me that "SELECT caches the converted value, while UPDATE
>>> does not". Where/how SELECT was doing it ? Why UPDATE wasn't ?
>> I was wrong, constants are cached only if they can be compared as ints
>> by convert_constant_item. It's called at fix_fields, thus it's
>> available for UPDATE also.
>>> Why do you need to introduce the concept of "late caching" ?
>> Because the value to be cached isn't always available at the moment of
>> cache creation.
>> Here is an example from our test suite:
>> SELECT (SELECT 1.5,'c','a') = ROW(1.5,2,'a');
>> Subselect uses Item_cache to cache it's result and it has the type of
>> the column.
>> Comparators for row comparison are created at the fix_field moment and
>> as subselect is only prepared subselect's cache doesn't contain anything.
>> Because of this here we will have wrong result.
> It might be simpler to just transform this table-less subquery into a
> ROW expression.
We don't do such tings in select list and allowing this will require a serious
work, AFAIU. Beside this subquery conversion isn't a matter of this bug and
this fix is a wrong place for adding such things.
If you think we definitely should have this feature then you can add a worklog
(or find an already present, very probably such things were already proposed)
and push it to make it implemented.