Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg
Date
Msg-id CAFjFpRe9W5xvYai-QOs6RshrJf7gWFsiZEZtxnu8vD4qLQZ3LQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Jun 7, 2017 at 10:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jun 6, 2017 at 3:23 PM, David Fetter <david@fetter.org> wrote:
>> I'd bet on lack of tuits.
>
> I expect that was part of it.  Another thing to consider is that, for
> numeric aggregates, the transition values don't generally get larger
> as you aggregate, but for something like string_agg(), they will.
> It's not clear how much work we'll really save by parallelizing that
> sort of thing.  Maybe it will be great?

+1, I was thinking about the same. There might be some cases when the
output of array_agg/string_agg is not a lot wider but the underlying
scans are large e.g. having clause containing another aggregate and
very small group sizes. I am not sure how frequent are such usecases.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company



pgsql-hackers by date:

Previous
From: "K S, Sandhya (Nokia - IN/Bangalore)"
Date:
Subject: Re: [HACKERS] [BUGS] Crash observed during the start of the Postgres process
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Broken hint bits (freeze)