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: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>,
Stephen Frost <sfrost@snowman.net>,
Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-28T13:54:38Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > On 03/28/2018 05:28 AM, Tom Lane wrote: >> Getting a solution that would work for other polymorphic serialization >> functions seems like a bit of a research project to me. In the meantime, >> I think David's right that what we need to look at is the actual input >> type of the aggregate, and then assume that what's to be serialized is >> an array of that. Conceivably an aggregate could be built that uses >> these serial/deserial functions and yet its input type is something else >> than what it constructs an array of ... but I find it a bit hard to >> wrap my brain around what that would be exactly. > But David's fix doesn't check the aggregate to produce an array of the > input type (or anyarray). It could easily be an aggregate computing a > bloom filter or something like that, which has no such issues in the > serial/deserial functions. Oh, if he's not restricting it to these serialization functions, I agree that seems wrong. I thought the discussion was about what to do after checking the functions. > Also, if it's checking aggref->aggargtypes, it'll reject anyelement > parameters, no? I had in mind to look at exprType() of the argument. 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