Re: Parallel Aggregate

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Parallel Aggregate
Дата
Msg-id CAKJS1f9yNf-RaTkP5cxG52LBYdsiEw8VsYdjtStV-BTnOFAU5g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Aggregate  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 17 March 2016 at 18:05, David Rowley <david.rowley@2ndquadrant.com> wrote:
> Updated patch attached.

Please disregard
0001-Allow-aggregation-to-happen-in-parallel_2016-03-17.patch. This
contained a badly thought through last minute change to how the Gather
path is generated and is broken.

I played around with ways of generating the Gather node as
create_gather_path() is not really geared up for what's needed here,
since grouped_rel cannot be passed into create_gather_path() since it
contains the final aggregate PathTarget rather than the partial
PathTarget, and also incorrect row estimates. I've ended up with an
extra double *rows argument in this function to make it possible to
override the rows from rel. I'm not sure how this'll go down... It
does not seem perfect.

In the end I've now added a new upper planner type to allow me to
create a RelOptInfo for the partial aggregate relation, so that I can
pass create_gather_path() a relation with the correct PathTarget. This
seemed better than borrowing grouped_rel, then overriding the
reltarget after create_gather_path() returned. Although I'm willing to
consider the option that someone will disagree with how I've done
things here.

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Kuleshov
Дата:
Сообщение: initdb: introduce PG_CMD_PRINTF intestead of PG_CMD_PRINTF{1,2,3}
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Aggregate