Re: GROUPING SETS revisited

2010/8/3 Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>:
> 2010/8/3 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> Hello
>>
>> 2010/8/3 Joshua Tolley <eggyknap(at)gmail(dot)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
>