Horton

Re: Making aggregate deserialization (and WAL receive) functions slightly faster

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-04T03:57:29Z
Lists: pgsql-hackers 
On Tue, Oct 03, 2023 at 06:02:10PM +1300, David Rowley wrote:
> I know I said I'd drop this, but I was reminded of it again today.  I
> ended up adjusting the patch so that it no longer adds a helper
> function to stringinfo.c and instead just manually assigns the
> StringInfo.data field to point to the bytea's buffer.  This follows
> what's done in some existing places such as
> LogicalParallelApplyLoop(), ReadArrayBinary() and record_recv() to
> name a few.
> 
> I ran a fresh set of benchmarks on today's master with and without the
> patch applied. I used the same benchmark as I did in [1].  The average
> performance increase from between 0 and 12 workers is about 6.6%.
> 
> This seems worthwhile to me.  Any objections?

Interesting.

+       buf.len = VARSIZE_ANY_EXHDR(sstate);
+       buf.maxlen = 0;
+       buf.cursor = 0;

Perhaps it would be worth hiding that in a macro defined in
stringinfo.h?
--
Michael

Commits

  1. Make use of initReadOnlyStringInfo() in more places

  2. Optimize various aggregate deserialization functions, take 2

  3. Introduce the concept of read-only StringInfos

  4. Revert "Optimize various aggregate deserialization functions"

  5. Optimize various aggregate deserialization functions