2010/8/3 Hitoshi Harada <umi.tan...@gmail.com>:
> 2010/8/3 Pavel Stehule <pavel.steh...@gmail.com>:
>> Hello
>> 2010/8/3 Joshua Tolley <eggyk...@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.



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

> Regards,
> --
> Hitoshi Harada

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to