Horton

Re: Parallel Aggregates for string_agg and array_agg

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Zhihong Yu <zyu@yugabyte.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas.vondra@enterprisedb.com>
Date: 2022-08-03T03:05:31Z
Lists: pgsql-hackers 
On Wed, 3 Aug 2022 at 14:40, Zhihong Yu <zyu@yugabyte.com> wrote:
> For array_agg_combine():
>
> +       if (state1->alen < reqsize)
> +       {
> +           /* Use a power of 2 size rather than allocating just reqsize */
> +           state1->alen = pg_nextpower2_32(reqsize);
> ...
> +       state1->nelems = reqsize;
>
> I wonder why pg_nextpower2_32(reqsize) is used in the if block. It seems reqsize should suffice.

It would suffice, but it's a question of trying to minimise the
reallocations. There might be many parallel workers to combine results
from. Nothing says this one is the last call to combine the given
aggregate state. As far as aset.c allocations, for small / medium
allocations, the actual memory is allocated in powers of 2 anyway. If
you request less, you'll maybe need to repalloc more often,
needlessly. The actual underlying allocation might be big enough
already, it's just that the palloc() caller does not have knowledge of
that.

David

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.