maria-developers team mailing list archive

[Zardosht Kasheff <zardosht@xxxxxxxxx>]

Hello Sergei,

I think both points make sense. We implemented prepare_range_scan
because it was easier and less risky. Both work for us. We would just
need to know the first release of MariaDB that has these changes so
that we can adjust our handlerton accordingly.

Thanks
-Zardosht

On Wed, May 2, 2012 at 10:25 AM, Sergei Golubchik <serg@xxxxxxxxxxxx> wrote:
> Hi, Zardosht!
>
> 1.
> I think prepare_index_scan() is just a special case of
> prepare_index_key_scan() (key length is 0).
> That is, there no need to have to methods, and one is enough.
> But it's a minor thing.
>
> 2.
> A larger one - I don't agree with the prepare_range_scan() change.
> Because it's just a workaround.
> You'd described the proper fix in the MySQL's bug tracker -
> there should be a version of read_range and multi-read-range
> for reverse index scans.
>
> Would that work for you? I mean both 1 and 2 above.
>
> On May 01, Zardosht Kasheff wrote:
>>
>> Attached is a proposed patch of new handler APIs. The purpose of this
>> patch is to give storage engines more information about impending
>> range queries. The idea is if MySQL is about to perform a range query
>> from a to b, then the handler is informed that a range query is about
>> to happen.
>>
>> It extends functionality like handler::prepare_index_scan to other
>> scenarios. We use it to know how much data to prefetch and prelock
>> before doing a range query.
>>
> Regards,
> Sergei