[FRG-359] fix regression in efficient subquery decorrelation introduced by Julian

[author="jvs", created="Mon, 3 Nov 2008 14:40:49 -0500 (GMT-05:00)"] « Hide
Rushan Chen wrote:

Hi John,

First, the plan change to ineffcient decorrelation is caused by the
change in pattern. The rule RemoveCorrelationForScalarAggregateRule
now needs to recognize AggRel without output projRel. This can be
easily fixed. Other plan changes in the ref file seems to be
improvements.

Oh, I see. This only affects cases where the aggregate is inside the
subquery, which is a pattern we don't currently use (we use aggregate
outside the subquery), so maybe it's OK if I integ first and just file
a JIRA issue to get it re-optimized?

You are right about the query that generates the pattern. If the
aggregate function is inside the select, then the AggRel will appear
before the Correlation(as input now without the project); otherwise, the
aggregate will be after the correlation as it aggregates over the result
of correlated query results. The efficient decorrelation for the latter
is taken care of by a different rule:
RemoveCorrelationForScalarProjectRule.

I will resolve the rule pattern matching problem once the integ is in
lu/dev. It should be fairly simple.

Rushan

John Sichi - 31/Oct/07 12:55 PM eigenchange 10134 integrates the regression-causing change from Julian to lu/dev.

LucidDB / luciddb

[FRG-359] fix regression in efficient subquery decorrelation introduced by Julian #513