Re: Parallel Aggregates for string_agg and array_agg
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-29T13:09:33Z
Lists: pgsql-hackers
On 30 March 2018 at 02:00, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > On 03/29/2018 05:49 AM, David Rowley wrote: >> Attached is v9, which is based on Tom's v8 but includes the new tests >> and I think the required fix to disable use of the serial/deserial >> function for array_agg(). >> > > I have only looked at the diff, but it seems fine to me (in the sense > that it's doing the right checks to disable parallelism only when really > needed). > > FWIW I wonder if we might simply fallback to input/output functions when > the send/receive functions are not available. Not sure it's worth it. I think it's a corner case to have a type without send/receive, but I might just be lacking imagination. I meant to mention earlier that I coded agg_args_have_sendreceive_funcs() to only check for send/receive functions. Really we could allow a byval types without send/receive functions, since the serial/deserial just send the raw datums in that case, but then the function becomes agg_byref_args_have_sendreceive_funcs(), which seemed a bit obscure, so I didn't do that. Maybe I should? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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