Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve index-ANDing by selectively pushing applying equalities below the intersection #2764

Open
normen662 opened this issue Jun 17, 2024 · 0 comments
Labels
planner Related to the query planner

Comments

@normen662
Copy link
Contributor

While working on #2748 I noticed that the ordering that is computed and reasoned about in AbstractDataAccessRule is the sort order that is achieved when realized and compensated matches are intersected when in fact the intersection is created prior to applying the intersected compensation on the individual legs of the intersection. That sort order may be different (see FDBNestedFieldQueryTest.nestedThenWithAndPartial()) where an equality predicate is applied as part of the compensation which only makes the intersection applicable after that equality predicate is applied (as compensation).

Note that index value columns are not really interesting here as they don't contribute to orderings. An equality predicate of an index key is only not applied as part of the index arguments if it is not part of the bound prefix of that match.

In #2748 I added some logic to demote an already established MatchedOrderingPart that uses an equality if that ordering part is not part of the bound prefix of the match. This approach, while correcting for incorrect plans, however, eliminates interesting orderings that can allow intersections to happen.

In general, the approach to defer compensation until after the intersection is the right one since any leg can filter a predicate AND it may be possible to implement a special intersection operator on index scans that works like a zig-zag join (in the future). What we really want here is to create a pre compensation for equality predicates so that we don't lose interesting orders that can partake in index ANDing.

Example:

index a: (a, b, c)
index b: (a, c)

 SELECT * FROM T WHERE a > 10 AND b = 5

left: using index a yielding order after compensation (a-up, b =, c up)
right: using index b order after compensation (a up, c up)
intersection order computed without demotion: (a up, c up) (one example as a and b float freely)

Intersectio cannot be applied using a realized intersection as b=5 is not applied to left.

@normen662 normen662 added the planner Related to the query planner label Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
planner Related to the query planner
Projects
None yet
Development

No branches or pull requests

1 participant