Re: Windowing Qual Pushdown

Поиск
Список
Период
Сортировка
От Hitoshi Harada
Тема Re: Windowing Qual Pushdown
Дата
Msg-id e08cc0401003230701l6ea8935bqf3cb367a3a7111c6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Windowing Qual Pushdown  (Daniel Farina <drfarina@acm.org>)
Список 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 по дате отправления:

Предыдущее
От: Gokulakannan Somasundaram
Дата:
Сообщение: Re: Deadlock possibility in _bt_check_unique?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Windowing Qual Pushdown