Re: Making aggregate deserialization (and WAL receive) functions slightly faster - Mailing list pgsql-hackers

From David Rowley
Subject Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Date
Msg-id CAApHDvoWPF6PRXdzsPVSArLa_hqUnjapsOZGptRQ_CWKYeqsRw@mail.gmail.com
Whole thread Raw
In response to Re: Making aggregate deserialization (and WAL receive) functions slightly faster  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Making aggregate deserialization (and WAL receive) functions slightly faster
List pgsql-hackers
On Sun, 12 Feb 2023 at 19:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I find this patch horribly dangerous.

I see LogicalRepApplyLoop() does something similar with a
StringInfoData. Maybe it's just scarier having an external function in
stringinfo.c which does this as having it increases the chances of
someone using it for the wrong thing.

> It could maybe be okay if we added the capability for StringInfoData
> to understand (and enforce) that its "data" buffer is read-only.
> However, that'd add overhead to every existing use-case.

I'm not very excited by that.  I considered just setting maxlen = -1
in the new function and adding Asserts to check for that in each of
the appendStringInfo* functions. However, since the performance gains
are not so great, I'll probably just drop the whole thing given
there's resistance.

David



pgsql-hackers by date:

Previous
From: Ankit Kumar Pandey
Date:
Subject: Re: Sort optimizations: Making in-memory sort cache-aware
Next
From: Andrew Dunstan
Date:
Subject: Re: run pgindent on a regular basis / scripted manner