You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The Ordering::pullUp calls Value::pullUp to pull up the values used in the equality bound map, but
The Value::pullUp method works by trying to translate parts of the result value according. However,
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.
The text was updated successfully, but these errors were encountered:
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:
(Meaning that we scan the
abIndex
and then rename fielda
asx
and fieldb
asy
.) In this case, we note that the order of the index scan follows theabIndex
is[a, b]
, but the order ofSELECT
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: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 aValueComparison
(it actually works with aSimpleComparison
or aParameterComparison
). In particular, the problem appears to be that:Ordering::pullUp
callsValue::pullUp
to pull up the values used in the equality bound map, butValue::pullUp
method works by trying to translate parts of the result value according. However,resultValue
tree. In particular,LiteralValue
s,ConstantObjectValue
s, and justQuantifiedObjectValue
s (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 theresultValue
treeAs 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 theOrdering
values until it is dropped as it is here.The text was updated successfully, but these errors were encountered: