David Rowley <david.row...@2ndquadrant.com> writes: > On 27 March 2018 at 09:27, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I do not think it is accidental that these aggregates are exactly the ones >> that do not have parallelism support today. Rather, that's because you >> just about always have an interest in the order in which the inputs get >> aggregated, which is something that parallel aggregation cannot support.
> This very much reminds me of something that exists in the 8.4 release notes: >> SELECT DISTINCT and UNION/INTERSECT/EXCEPT no longer always produce sorted >> output (Tom) That's a completely false analogy: we got a significant performance benefit for a significant fraction of users by supporting hashed aggregation. My argument here is that only a very tiny fraction of string_agg/array_agg users will not care about aggregation order, and thus I don't believe that this patch can help very many people. Against that, it's likely to hurt other people, by breaking their queries and forcing them to insert expensive explicit sorts to fix it. Even discounting the backwards-compatibility question, we don't normally adopt performance features for which it's unclear that the net gain over all users is positive. Maybe what that says is that rather than giving up on this altogether, we should shelve it till we have less stupid planner+executor behavior for ORDER BY inside aggregates. That's been on the to-do list for a long while, but not risen to the top ... regards, tom lane