Re: Windowing Qual Pushdown - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Windowing Qual Pushdown
Date
Msg-id e08cc0401003230701l6ea8935bqf3cb367a3a7111c6@mail.gmail.com
Whole thread Raw
In response to Re: Windowing Qual Pushdown  (Daniel Farina <drfarina@acm.org>)
List pgsql-hackers
2010/3/23 Daniel Farina <drfarina@acm.org>:
> On Tue, Mar 23, 2010 at 12:40 AM, Hitoshi Harada <umi.tanuki@gmail.com> wrote:
>> I believe the changes will probably not be 2-3 lines (ie. a member
>> added to Query structure, etc) if I try it. But the optimizer part is
>> too complicated to me so that I am not sure, either. My idea above is
>> that the similar mechanism you see in GROUP BY optimization will help
>
> Are you suggesting that the windowing clause should perhaps refer to a
> column in the target list, much like GROUP BY/ORDER BY, so that  one
> can easily see if the qual in the fromexpr corresponds to the
> windowClause to see if the pushdown is safe?

The windowing clause refer to the targetlist as resjunk columns. I
thought we need some intermediate data like havingQual to tell what is
pushed down to subquery, because the pushdown of GROUP BY columns is
done later in subquery_planner() of the subquery (as pushed-down
havingQual), not in set_subquery_pathlist().

However, I found the real problem. If the query has multiple window
definitions, at this stage you cannot tell if the pushdown is safe nor
cannot know how, because the order of evaluation of individual window
is decided later in grouping_planner(). So the workaround is to limit
this optimization for only one window definition case but it seems too
narrow solution.

Maybe there're chances in setrefs.c to do it after grouping_planner(),
but I'm not quite sure.

Regards,


--
Hitoshi Harada


pgsql-hackers by date:

Previous
From: Gokulakannan Somasundaram
Date:
Subject: Re: Deadlock possibility in _bt_check_unique?
Next
From: Tom Lane
Date:
Subject: Re: Windowing Qual Pushdown