GROUPING SETS revisited
in [PgSql]
|
From: Pavel Stehule on 3 Aug 2010 02:35 Hello 2010/8/3 Joshua Tolley <eggyknap(a)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 comments?? Regards Pavel > [1] http://archives.postgresql.org/pgsql-hackers/2009-05/msg00700.php > > -- > Joshua Tolley / eggyknap > End Point Corporation > http://www.endpoint.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkxXrggACgkQRiRfCGf1UMMlCQCglaIdtPj8Qe6G60V2LHn5pFNn > kgIAniXRgIQEbVrK/eDVZnmKCzw33lT9 > =XVVV > -----END PGP SIGNATURE----- > > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Hitoshi Harada on 3 Aug 2010 07:24 2010/8/3 Pavel Stehule <pavel.stehule(a)gmail.com>: > Hello > > 2010/8/3 Joshua Tolley <eggyknap(a)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. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 3 Aug 2010 07:43 2010/8/3 Hitoshi Harada <umi.tanuki(a)gmail.com>: > 2010/8/3 Pavel Stehule <pavel.stehule(a)gmail.com>: >> Hello >> >> 2010/8/3 Joshua Tolley <eggyknap(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 3 Aug 2010 15:58 On Mon, Aug 02, 2010 at 11:50:00PM -0600, Josh Tolley wrote: > 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. > > [1] > http://archives.postgresql.org/pgsql-hackers/2009-05/msg00700.php I've added back one file in the patch enclosed here. I'm still getting compile fails from CC="ccache gcc" ./configure --prefix=$PG_PREFIX --with-pgport=$PGPORT --with-perl --with-libxml --enable-debug --enable-cassert make Log from that also enclosed. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
From: Joshua Tolley on 3 Aug 2010 16:20 On Tue, Aug 03, 2010 at 12:58:03PM -0700, David Fetter wrote: > On Mon, Aug 02, 2010 at 11:50:00PM -0600, Josh Tolley wrote: > > 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. > > > > [1] > > http://archives.postgresql.org/pgsql-hackers/2009-05/msg00700.php > > I've added back one file in the patch enclosed here. I'm still > getting compile fails from > > CC="ccache gcc" ./configure --prefix=$PG_PREFIX --with-pgport=$PGPORT --with-perl --with-libxml --enable-debug --enable-cassert > make > > Log from that also enclosed. > Yeah, I seem to have done a poor job of producing the patch based on the repository I was working from. That said, it seems Pavel's working actively on a patch anyway, so perhaps my updating the old one isn't all that worthwhile. Pavel, is your code somewhere that we can get to it? -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
|
Next
|
Last
Pages: 1 2 3 Prev: [HACKERS] GROUPING SETS revisited Next: [HACKERS] Where in the world is Itagaki Takahiro? |