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

  1. Fix unstable aggregate regression test

  2. Allow parallel aggregate on string_agg and array_agg

  3. Improve performance of ORDER BY / DISTINCT aggregates

  4. Support ORDER BY within aggregate function calls, at long last providing a

  5. Fix broken markup.