| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Subject: | Re: WIP Patch for GROUPING SETS phase 1 |
| Date: | 2014-09-09 16:43:05 |
| Message-ID: | 87lhps69jg.fsf@news-spur.riddles.org.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> Honestly, ChainAggregate is _trivial_ compared to trying to make the
>>> GroupAggregate code deal with multiple inputs, or trying to make some
>>> new sort of plumbing node to feed input to those sorts. (You'd think
>>> that it should be possible to use the existing CTE mechanics to do it,
>>> but noooo... the existing code is actively and ferociously hostile to
>>> the idea of adding new CTEs from within the planner.)
>> That's unfortunate.
Tom> I'm less than convinced that it's true ...
Maybe you can figure out how, but I certainly didn't see a reasonable way.
I would also question one aspect of the desirability - using the CTE
mechanism has the downside of needing an extra tuplestore with the
full input data set in it, whereas the chain mechanism only has
aggregated data in its tuplestore which should be much smaller.
--
Andrew (irc:RhodiumToad)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2014-09-09 16:45:47 | Add shutdown_at_recovery_target option to recovery.conf |
| Previous Message | Petr Jelinek | 2014-09-09 16:33:46 | Re: pg_background (and more parallelism infrastructure patches) |