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 <dgrowleyml@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
Robert Haas <robertmhaas@gmail.com>,
Stephen Frost <sfrost@snowman.net>,
Andres Freund <andres@anarazel.de>,
Tomas Vondra <tomas.vondra@enterprisedb.com>
Date: 2022-08-03T00:18:20Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > Waking up this old thread again. If you don't have a copy, the entire > thread is in [1]. > The remaining item that seemed to cause this patch to be rejected was > raised in [2]. Hmm. My estimate of the percentages of users who will be pleased or not hasn't really changed since [2]. Also, realizing that you can't apply these aggregates to extremely large input sets, I wonder just how much it buys to be able to parallelize them. So I still put this patch in the category of "just because we can doesn't mean we should". Now as against that, if the underlying relation scan is parallelized then you already have unpredictable input ordering and thus unpredictable aggregate results. So anyone who cares about that has already had to either disable parallelism or insert an ORDER BY somewhere, and either of those fixes will still work if the aggregates support parallelism. Hence, I'm not going to fight hard if you really want to do it. But I remain unconvinced that the cost/benefit tradeoff is attractive. 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