Horton

Re: appendBinaryStringInfo stuff

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-12-19T22:26:26Z
Lists: pgsql-hackers 
On Tue, 20 Dec 2022 at 09:23, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> AFAICT, the code in question is for the text output of the jsonpath
> type, which is used ... for barely anything?

I think the performance of a type's output function is quite critical.
I've seen huge performance gains in COPY TO performance from
optimising output functions in the past (see dad75eb4a and aa2387e2f).
It would be good to see some measurements to find out how much adding
the strlen calls back in would cost us. If we're unable to measure the
change, then maybe the cleanup patch would be nice. If it's going to
slow COPY TO down 10-20%, then we need to leave this or consider the
inline function mentioned by Andres or the macro trick mentioned by
me.

David

Commits

  1. Change argument type of pq_sendbytes from char * to void *

  2. Remove useless casts to (void *) in hash_search() calls

  3. Change argument of appendBinaryStringInfo from char * to void *

  4. Use appendStringInfoString instead of appendBinaryStringInfo where possible