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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Date: 2023-10-15 16:56:29
Message-ID: 2094149.1697388989@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I spent more time on this and did end up with 2 new init functions as
> you mentioned. One for strictly read-only (initReadOnlyStringInfo),
> which cannot be appended to, and as you mentioned, another
> (initStringInfoFromString) which can accept a palloc'd buffer which
> becomes managed by the stringinfo code. I know these names aren't
> exactly as you mentioned. I'm open to adjusting still.

This v3 looks pretty decent, although I noted one significant error
and a few minor issues:

* in initStringInfoFromString, str->maxlen must be set to len+1 not len

* comment in exec_bind_message doesn't look like pgindent will like it

* same in record_recv, plus it has a misspelling "Initalize"

* in stringinfo.c, inclusion of pg_bitutils.h seems no longer needed

I guess the next question is whether we want to stop here or
try to relax the requirement about NUL-termination. I'd be inclined
to call that a separate issue deserving a separate commit, so maybe
we should go ahead and commit this much anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2023-10-15 17:48:51 Re: Logging parallel worker draught
Previous Message vignesh C 2023-10-15 16:25:18 Re: pg_upgrade's interaction with pg_resetwal seems confusing