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: David Rowley <david.rowley@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-26T23:49:24Z
Lists: pgsql-hackers
I wrote:
> The main thing that remains undone is to get some test coverage ---
> AFAICS, none of these new functions get exercised in the standard
> regression tests.
Oh, I thought of another thing that would need to get done, if we decide
to commit this. array_agg_serialize/deserialize only work if the array
element type has send/receive functions. The planner's logic to decide
whether partial aggregation is possible doesn't look any deeper than
whether the aggregate has serialize/deserialize, but I think we have to
teach it that if it's these particular serialize/deserialize functions,
it needs to check the array element type. Otherwise we'll get runtime
failures if partial aggregation is attempted on array_agg().
This would not matter for any core datatypes, since they all have
send/receive functions, but I imagine it's still pretty common for
extension types not to.
For my money it'd be sufficient to hard-code the test like
if ((aggserialfn == F_ARRAY_AGG_SERIALIZE ||
aggdeserialfn == F_ARRAY_AGG_DESERIALIZE) &&
!array_element_type_has_send_and_recv(exprType(aggregate input)))
Someday we might need more flexible testing, but that can be solved
some other time.
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