[MDEV-23808] Optimising range based multilevel date index Created: 2020-09-24 Updated: 2020-09-25 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Optimizer |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Himanshu Mishra | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
Let's assume a table
With sufficient data, let's assume following query is fired.
This query doesn't use name part of index due to range based search on creation column. However, changing above query to
This uses creation as well as name part of index as now we've specified absolute values. Query1 can be optimised by the optimiser, since date field can only contain individual date values, range search caused by between can be optimised to in operator if range is short. That way index can be fully utilised. Another solution is reversing the index order to name, creation instead of creation, date, however that causes randomised insertions in index, instead of sequential one, which AFAIK is bad for loading into buffer and causes page splits. |
| Comments |
| Comment by Sergei Golubchik [ 2020-09-25 ] |
|
Basically, you're saying that if there's an index on a,b and WHERE clause with a range condition on a and some (range or exact) condition on b, then the range can be replaced with an IN enumerating all values of a in the range. That will allow to use the condition on b too. Sure, this makes sense. Optimizer will need to take care to avoid blowing up the range tree with too many values. Another option would be not to replace BETWEEN with IN explicitly, but to use loose index scan internally. |