[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

create table foo (
name varchar(140),
creation date,
index index_on_creation_name(creation, name)
)

With sufficient data, let's assume following query is fired.

query1

select 1 from foo where creation between curdate() - interval 2 day and curdate() and name = "bar";

This query doesn't use name part of index due to range based search on creation column.

However, changing above query to

query2

 
select 1 from foo where creation in (curdate() - interval 2 day, curdate() - interval 1 day, curdate()) and name = "bar";

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.

Generated at Thu Feb 08 09:25:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.