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
-
Fix unstable aggregate regression test
- f5d0e866404a 16.3 landed
- d6a6957d53e3 17.0 landed
-
Allow parallel aggregate on string_agg and array_agg
- 16fd03e95654 16.0 landed
-
Improve performance of ORDER BY / DISTINCT aggregates
- 1349d2790bf4 16.0 cited
-
Support ORDER BY within aggregate function calls, at long last providing a
- 34d26872ed81 9.0.0 cited
-
Fix broken markup.
- 6a6efb964092 9.0.0 cited