Hi, Øystein!
On Sep 28, Øystein Grøvlen wrote:
> Evgeny Potemkin wrote:
> >
> > 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.
If you doubt that this patch provides any performance benefits, you can
ask Evgeny to run few simple benchmarks to explore the effects of the
patch.
Regards / Mit vielen Grüßen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
/_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028
<___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring
