Re: GROUPING SETS revisited

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: GROUPING SETS revisited
Дата
Msg-id AANLkTinvjTUJ7pYoSZq1Jp89skfO8zTE7d9Z+O2o6+SB@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GROUPING SETS revisited  (Hitoshi Harada <umi.tanuki@gmail.com>)
Список pgsql-hackers
2010/8/3 Hitoshi Harada <umi.tanuki@gmail.com>:
> 2010/8/3 Pavel Stehule <pavel.stehule@gmail.com>:
>> Hello
>>
>> 2010/8/3 Joshua Tolley <eggyknap@gmail.com>:
>>> In case anyone's interested, I've taken the CTE-based grouping sets patch from
>>> [1] and made it apply to 9.1, attached. I haven't yet done things like checked
>>> it for whitespace consistency, style conformity, or anything else, but (tuits
>>> permitting) hope to figure out how it works and get it closer to commitability
>>> in some upcoming commitfest.
>>>
>>> I mention it here so that if someone else is working on it, we can avoid
>>> duplicated effort, and to see if a CTE-based grouping sets implementation is
>>> really the way we think we want to go.
>>>
>>
>> I am plaing with it now :). I have a plan to replace CTE with similar
>> but explicit executor node. The main issue of existing patch was using
>> just transformation to CTE. I agree, so it isn't too much extensiable
>> in future. Now I am cleaning identifiers little bit. Any colaboration
>> is welcome.
>>
>> My plan:
>> 1) clean CTE patch
>> 2) replace CTE with explicit executor node, but still based on tuplestore
>> 3) when will be possible parallel processing based on hash agg - then
>> we don't need to use tuplestore
>
> Couldn't you explain what exactly "explicit executor node"? I hope we
> can share your image to develop it further than only transformation to
> CTE.

I have a one reason

Implementation based on CTE doesn't create space for possible
optimalisations (I think now, maybe it isn't true). It is good for
initial or referencial implementation - but it can be too complex,
when we will try to append some optimalizations - like parallel hash
agg processing, direct data reading without tuplestore. If you are, as
CTE author, thinking so these features are possible in non recursive
CTE too, I am not agains. I hope so this week I'll have a CTE based
patch - and we can talk about next direction. I see as possible
performance issue using a tuplestore - there are lot of cases where
repeating of source query can be faster.

If I remember well, Tom has a objection, so transformation to CTE is
too early - in parser. So It will be first change. Executor node can
be CTE.

regards

Pavel

p.s. I am sure, so there are lot of task, that can be solved together
with non recursive CTE.

>
>
> Regards,
>
> --
> Hitoshi Harada
>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: GROUPING SETS revisited
Следующее
От: Viktor Valy
Дата:
Сообщение: Develop item from TODO list