Re: Pull up aggregate subquery

2011/5/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, May 25, 2011 at 10:35 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
>> 2011/5/25 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
>>> So I'm still
>>> thinking which of pulling up and parameterized scan is better.
>>
>> After more investigation I came up with third idea, pushing down
>> RangeTblEntry to aggregate subquery. This sounds like a crazy idea,
>> but it seems to me like it is slightly easier than pulling up
>> agg-subquery. The main point is that when you want to pull up, you
>> must care if the final output would be correct with other join
>> relations than the aggregate-related one. In contrast, when pushing
>> down the target relation to agg-subquery it is simple to ensure the
>> result.
>>
>> I'm looking around pull_up_subqueries() in subquery_planner() to add
>> the pushing down logic. It could be possible to do it around
>> make_one_rel() but I bet query structure changes are doable against
>> Query, not PlannerInfo.
>
> How do you decide whether or not to push down?

Yeah, that's the problem. In addition to the conditions of join-qual
== grouping key && outer is unique on qual, we need some criteria if
it should be done. At first I started to think I can compare cost of
two different plan nodes, which are generated by calling
subquery_planner() twice. But now my plan is to apply some heuristics
like that join qual selectivity is less than 10% or so. I either don't
like magic numbers but given Query restructuring instead of
PlannerInfo (which means we cannot use Path) it is only left way. To
get it work is my first goal anyway.

Regards,

--
Hitoshi Harada