From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Grouping sets |
Date: | 2009-10-29 08:48:46 |
Message-ID: | 162867790910290148m4bc7b050p966cf1668b19b74e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
I got a possibility to continue on GROUPING SETS see
http://wiki.postgresql.org/wiki/Grouping_Sets
My last patch was based on an sharing functionality with non recursive
CTE. I would to recapitulate all options here and I would to prepare
this patch for next commitfest.
a) using actualised patch - review:
http://archives.postgresql.org/message-id/162867790811240316y52227d88xe53527399b329e05@mail.gmail.com
+ it is simple (share lot of code)
+ it is near to natural implementation - result is in "good" order
+ allows full implementation of ANSI SQL syntax - GROUP BY
[>>ALL<<|DISTINCT] GROUPING SETS(..
- is serial
- I read some objections - "it is only syntactic sugar"
b) modification of a (directly using tuple store without CTE code)
+ add some new code
- it isn't syntactic sugar
c) go back to my first patch and use "feeders"
- add some complexity to GROUP BY planner ( :-( )
+/- add new concept to PostgreSQL - semi parallel execution
- when datatype isn't hashable, then have to use serial processing
- have to solve some corner behave of our hashtable support
- should be very fast
I still prefer option a (with some cleaning)
I invite any comments and helpers.
Regards
Pavel Stehule
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2009-10-29 08:54:24 | Re: [PATCHES] updated hash functions for postgresql v1 |
Previous Message | Pavel Stehule | 2009-10-29 07:48:01 | Re: Proposal - temporal contrib module |