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
This is a sub-issue of #10632 to narrow down a specific problem.
Say you have a query of the form:
SELECT * FROM (SELECT a+2, b*3 FROM foo) AS bar(x,y) WHERE x = y
and we want to propagate x=y to the data source SELECT b+2, a*3 FROM foo.
In the initial query the WHERE predicate is an expression expressed as ComparisonExpr{Eq, @1, @2} (using the @ syntax for indexed vars introduced in #10729). In this context the Indexedvars refer to positions in the outer select's data source, which is opaque at that level. The only thing the outer select knows is that its data source returns two columns, and thus the references @1 and @2 are valid.
Based on the interface described in #10632, the pushPredicateDown method is called on the inner selectNode, with the aforementioned filter expression ComparisonExpr{Eq, @1, @2} . Within the context of the inner select, the indexedvars in this predicate now refer to the two rendered expressionsb+2 and a*3.
So first thing the pushPredicateDown method must translate the predicate to refer to the inner select's data sources. That is it needs to translate @1=@2 to b+2=a*3 (which in turn will be encoded as @2+2 = @1*3, now referring to the inner select's own data source).
This is the issue being described here: implement the substitution of indexedvars incoming from the outer context in selectNode.pushPredicateDown by the render expressions that already exist in the current selectNode.
The resulting expressions must be normalized (simplified) after the substitution, before further recursing with pushPredicateDown as indicated in #10632.
The text was updated successfully, but these errors were encountered:
This is a sub-issue of #10632 to narrow down a specific problem.
Say you have a query of the form:
SELECT * FROM (SELECT a+2, b*3 FROM foo) AS bar(x,y) WHERE x = y
and we want to propagate
x=y
to the data sourceSELECT b+2, a*3 FROM foo
.In the initial query the WHERE predicate is an expression expressed as
ComparisonExpr{Eq, @1, @2}
(using the @ syntax for indexed vars introduced in #10729). In this context the Indexedvars refer to positions in the outer select's data source, which is opaque at that level. The only thing the outer select knows is that its data source returns two columns, and thus the references @1 and @2 are valid.Based on the interface described in #10632, the
pushPredicateDown
method is called on the inner selectNode, with the aforementioned filter expressionComparisonExpr{Eq, @1, @2}
. Within the context of the inner select, the indexedvars in this predicate now refer to the two rendered expressionsb+2
anda*3
.So first thing the
pushPredicateDown
method must translate the predicate to refer to the inner select's data sources. That is it needs to translate@1=@2
tob+2=a*3
(which in turn will be encoded as@2+2 = @1*3
, now referring to the inner select's own data source).This is the issue being described here: implement the substitution of indexedvars incoming from the outer context in
selectNode.pushPredicateDown
by the render expressions that already exist in the current selectNode.The resulting expressions must be normalized (simplified) after the substitution, before further recursing with
pushPredicateDown
as indicated in #10632.The text was updated successfully, but these errors were encountered: