From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, Regina Obe <lr(at)pcorp(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Aggregation support for aggregate functions that use transitions not implemented for array_agg |
Date: | 2017-06-08 12:36:19 |
Message-ID: | CAFjFpRe9W5xvYai-QOs6RshrJf7gWFsiZEZtxnu8vD4qLQZ3LQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 7, 2017 at 10:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jun 6, 2017 at 3:23 PM, David Fetter <david(at)fetter(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-06-08 12:58:44 | Re: Broken hint bits (freeze) |
Previous Message | K S, Sandhya (Nokia - IN/Bangalore) | 2017-06-08 12:25:14 | Re: [BUGS] Crash observed during the start of the Postgres process |