Re: WIP Patch for GROUPING SETS phase 1 - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: WIP Patch for GROUPING SETS phase 1
Date
Msg-id 87mwayqjv6.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to WIP Patch for GROUPING SETS phase 1  (Atri Sharma <atri.jiit@gmail.com>)
Responses Re: WIP Patch for GROUPING SETS phase 1
List pgsql-hackers
A progress update:
Atri>  We envisage that handling of arbitrary grouping sets will beAtri> best done by having the planner generating an
AppendofAtri> multiple aggregation paths, presumably with some way of movingAtri> the original input path to a CTE. We
havenot really exploredAtri> yet how hard this will be; suggestions are welcome.
 

This idea was abandoned.

Instead, we have implemented full support for arbitrary grouping sets
by means of a chaining system:

explain (verbose, costs off) select four, ten, hundred, count(*) from onek group by cube(four,ten,hundred);
                                            QUERY PLAN                                              
-----------------------------------------------------------------------------------------------------GroupAggregate
Output:four, ten, hundred, count(*)  Grouping Sets: (onek.hundred, onek.four, onek.ten), (onek.hundred, onek.four),
(onek.hundred),()  ->  Sort        Output: four, ten, hundred        Sort Key: onek.hundred, onek.four, onek.ten
-> ChainAggregate              Output: four, ten, hundred              Grouping Sets: (onek.ten, onek.hundred),
(onek.ten)             ->  Sort                    Output: four, ten, hundred                    Sort Key: onek.ten,
onek.hundred                   ->  ChainAggregate                          Output: four, ten, hundred
      Grouping Sets: (onek.four, onek.ten), (onek.four)                          ->  Sort
Output: four, ten, hundred                                Sort Key: onek.four, onek.ten
-> Seq Scan on public.onek                                      Output: four, ten, hundred
 
(20 rows)

The ChainAggregate nodes use a tuplestore to communicate with the
GroupAggregate node at the top of the chain; they pass through input
tuples unchanged, and write aggregated result rows to the tuplestore,
which the top node then returns once it has finished its own result.

The organization of the planner code seems to be actively hostile to
any attempt to break out new CTEs on the fly, or to plan parts of the
query more than once; the method above seems to be the easiest way to
avoid those issues.
Atri> At this point we are more interested in design review ratherAtri> than necessarily committing this patch in its
currentstate.
 

This no longer applies; we expect to post within a day or two an
updated patch with full functionality.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Andreas 'ads' Scherbaum
Date:
Subject: Re: documentation update for doc/src/sgml/func.sgml
Next
From: Fabien COELHO
Date:
Subject: Re: documentation update for doc/src/sgml/func.sgml