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