Re: Parallel Aggregates for string_agg and array_agg

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Stephen Frost <sfrost@snowman.net>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-27T14:58:14Z
Lists: pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 27 March 2018 at 13:26, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> synchronized_seqscans is another piece of precedent in the area, FWIW.

> This is true. I guess the order of aggregation could be made more
> certain if we remove the cost based optimiser completely, and just
> rely on a syntax based optimiser.

None of this is responding to my point.  I think the number of people
who actually don't care about aggregation order for these aggregates
is negligible, and none of you have argued against that; you've instead
selected straw men to attack.

			regards, tom lane


Commits

  1. Fix unstable aggregate regression test

  2. Allow parallel aggregate on string_agg and array_agg

  3. Improve performance of ORDER BY / DISTINCT aggregates

  4. Support ORDER BY within aggregate function calls, at long last providing a

  5. Fix broken markup.