Re: WIP Patch for GROUPING SETS phase 1

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: WIP Patch for GROUPING SETS phase 1
Дата
Msg-id 87mwayqjv6.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на WIP Patch for GROUPING SETS phase 1  (Atri Sharma <atri.jiit@gmail.com>)
Ответы Re: WIP Patch for GROUPING SETS phase 1
Список 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 по дате отправления:

Предыдущее
От: Andreas 'ads' Scherbaum
Дата:
Сообщение: Re: documentation update for doc/src/sgml/func.sgml
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: documentation update for doc/src/sgml/func.sgml