Evgeny Potemkin wrote:
> Hi,
>
> The bug#34384 is about UPDATE being too slow.
>
> See:
> create table t(a int primary key, ...);
> insert ...
> update ... where a='9999999999999999';
>
> As you can see, a is an INT, and the constant is a STRING.
> To correctly compare them we convert both to DOUBLE.
> Obviously, in this case the index over "a" can't be used.
> Currently left & right parts of comparison are converted immediately
> before comparison is done. This is done for each row. It's ok for a
> field, but the converted constant can be cached. This patch implements
> caching of constants.
> This allows to speedup a bit comparison on large record sets, but isn't
> noticeable on small ones.
Hi,
In my opinion, performance fixes needs to be justified by some
quantitative measures. I do not think we should make the code more
complex unless it can be shown that it gives significant performance
benefits.
In this particular case, even if there is a significant performance
improvements in itself, it will be insignificant compared to what the
user could achieved by casting the string to an int.
Anyhow, I will leave it to Sergei to decide whether this is a desired
change or not, and get back to you with my specific comments on the
patch.
> The bug shown by Sergey is about wrongly used index for the SELECT
> i.e. a different one, and will be addressed in a different bug report.
OK, Good.
--
Øystein
