[Maria-developers] proposed patch for handler APIs for range query information
Hello all, After talking with Colin Charles last night, I have been encouraged to send more patches for MariaDB. Here is a hopefully simple one that benefits all storage engines. 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. Any storage engine can use this as a heuristic for optimizing range query performance. I would love to hear feedback -Zardosht
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
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@askmonty.org> 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
participants (2)
-
Sergei Golubchik -
Zardosht Kasheff