On Mon, Mar 26, 2018 at 4:27 PM, 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.
That's not the reason, as has been stated by the person who wrote the code. As the person who committed the code, my recollection of the reasoning involved matches his. > I fear that what will happen, if we commit this, is that something like > 0.01% of the users of array_agg and string_agg will be pleased, another > maybe 20% will be unaffected because they wrote ORDER BY which prevents > parallel aggregation, and the remaining 80% will scream because we broke > their queries. Telling them they should've written ORDER BY isn't going > to cut it, IMO, when the benefit of that breakage will accrue only to some > very tiny fraction of use-cases. I think your estimated percentages here are wildly inaccurate. I am in favor of this patch, like everyone else who has voted with the exception of you. I have not reviewed the code, but I firmly believe that preventing parallel query is far more damaging than breaking queries for whatever fraction of users are relying on behavior that wasn't guaranteed in the first place. I do understand your concern and I respect your opinion, so please do not take the fact that I do not agree with you in this case as an indication of disrespect. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company