Horton

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

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-30T20:55:21Z
Lists: pgsql-hackers 
On Mon, 30 Oct 2023 at 23:48, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Oct 27, 2023 at 3:23 AM David Rowley <dgrowleyml@gmail.com> wrote:
> > * parallel.c in HandleParallelMessages():
> > * applyparallelworker.c in HandleParallelApplyMessages():
>
> Both the above calls are used to handle ERROR/NOTICE messages from
> parallel workers as you have also noticed. The comment atop
> initReadOnlyStringInfo() clearly states that it is used in the
> performance-critical path. So, is it worth changing these places? In
> the future, this may pose the risk of this API being used
> inconsistently.

I'm ok to leave those ones out.  But just a note on the performance
side, if we go around needlessly doing palloc/memcpy then we'll be
flushing possibly useful cachelines out and cause slowdowns elsewhere.
That's a pretty hard thing to quantify, but something to keep in mind.

David

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