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. 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
