Answers are inline.
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
> 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
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.
> Regards / Mit vielen Grüßen,