maria-developers team mailing list archive

[Nayuta Yanagisawa <nayuta.yanagisawa@xxxxxxx>]

Hi Sergei,

Thank you for your review.

I just created the spider/bugfix directory for the consistency with the
later versions.
However, I do not have a strong opinion on it and your point sounds
reasonable.
So, I'll push the revised version again as such.

Regard,
Nayuta

On July 13, 2021, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> Hi, Nayuta!
>
> The code change is good, no comments about it at all.
>
> But why did you create a new suite spider/bugfix and all those files
> in
> it? I know that some later spider version has it. Still, I'd expect
> it'd
> be much simpler and a smaller change to drop the test file into the
> exising spider suite.
>
> On Jul 12, Nayuta Yanagisawa wrote:
> > revision-id: da70f190279 (mariadb-10.2.39-44-gda70f190279)
> > parent(s): 99f700a820e
> > author: Nayuta Yanagisawa <nayuta.yanagisawa@xxxxxxx>
> > committer: Nayuta Yanagisawa <nayuta.yanagisawa@xxxxxxx>
> > timestamp: 2021-07-08 14:12:45 +0000
> > message:
> > 
> > MDEV-25985 Spider handle ">=" as ">" in some cases
> > 
> > The function spider_db_append_key_where_internal() converts
> > HA_READ_AFTER_KEY to '>'. The conversion seems to be correct for
> > single-column indexes because HA_READ_AFTER_KEY means "read the
> > key after the provided value."
> > 
> > However, how about multi-column indexes? Assume that there is a
> > multi-column index on c1 and c2 and we search with the condition
> > 'c1 >= 100 AND c2 > 200'. The key_range.flag corresponds to the
> > search condition could be HA_READ_AFTER_KEY. In such a case,
> > we could not simply convert HA_READ_AFTER_KEY to '>'.
> > 
> > The correct conversion is to convert HA_READ_AFTER_KEY to '>'
> > only for the last column in key_part_map and to convert
> > HA_READ_AFTER_KEY to '>=' for the other column.
> > 
> > The similar discussion also applies to the conversion from
> > key_range.flag to a sign of inequality.
> > 
> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and security@xxxxxxxxxxx