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

Pulling up ordering values can drop equality value comparisons #2723

Open
alecgrieser opened this issue May 15, 2024 · 0 comments
Open

Pulling up ordering values can drop equality value comparisons #2723

alecgrieser opened this issue May 15, 2024 · 0 comments
Labels
planner Related to the query planner

Comments

@alecgrieser
Copy link
Contributor

As part of planning, we have situations where we take the ordering property and pull it through transformations. For example, if we have something like:

   (SELECT a AS x, b AS y FROM $q1) -> q1: [ Index(abIndex <,>) ]

(Meaning that we scan the abIndex and then rename field a as x and field b as y.) In this case, we note that the order of the index scan follows the abIndex is [a, b], but the order of SELECT is [x, y].

So far so good, but the other thing we model in the Orderings object are any equality predicates. So, if we had something like:

   (SELECT a AS x, b AS y FROM $q1) -> q1: [ Index(abIndex [EQUALS $aValue]) ]

Then we would model the order of the index scan as [b, a], b=$aValue. The select should similarly have its ordering modeled as [y, x], x=$aValue, but that equality bound information can be disrupted if the comparison is a ValueComparison (it actually works with a SimpleComparison or a ParameterComparison). In particular, the problem appears to be that:

  1. The Ordering::pullUp calls Value::pullUp to pull up the values used in the equality bound map, but
  2. The Value::pullUp method works by trying to translate parts of the result value according. However,
  3. Not all comparison values are in the resultValue tree. In particular, LiteralValues, ConstantObjectValues, and just QuantifiedObjectValues (which aren't necessarily constant, but can be treated as such if they are correlated to values that are still available in the parent context) are all common comparison values that won't be in the resultValue tree

As it turns out, this can have some interesting implications. In particular, it can mess up our ability to turn queries into IN-join plans if there is an ordering constraint on the IN value. That kind of operation is actually supported using the sorted in-source, which sorts the values in the list before running the operation, but we only chose to create that kind of plan if there are equality predicates in the right place. That information is recorded in the Ordering values until it is dropped as it is here.

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