[MDEV-20819] index_merge/[sort_]intersect should not scan non-overlapping rowid ranges Created: 2019-10-13 Updated: 2020-02-18 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Optimizer |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Sergei Petrunia | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | index_merge | ||
| Attachments: |
|
| Description |
|
This is a followup to the discussion here: The idea is that index_merge intersection and sort-intersection can avoid scanning the ranges of rowids that do not overlap with ranges of rowids produced by other scans. sort-intersect algorithmThe idea is:
Limitation #1: the range must use all keypartsif an index is defined as IDX(col1, col2, col3) Then it actually is
so ranges like
can be changed into
This is only possible when the range endpoints include col3. If this is not the case, we can't do that. Limitation #2: No open endpointsConsider a key IDX(col1) and a range:
The range starts with col1=11 and does not include any rows with col1=10. If we add the rowid, we will get
which does include rows with col1=10, which will make it worse, not better. ROR-intersect algorithm
ROR ranges always have the form "t.key=const" (where equalities on all key parts are present), which means
Other issuesunder what condition can SQL layer perform index reads with index lookup tuples that have rowids attached to their ends? |