Re: libpq: PQgetCopyData() and allocation overhead - Mailing list pgsql-hackers

From Jeroen Vermeulen
Subject Re: libpq: PQgetCopyData() and allocation overhead
Date
Msg-id CA+zULE7_7tLNiqiA4PZs5VQ9yzAxrNbSgfSBJxYN_q1bymo1Eg@mail.gmail.com
Whole thread Raw
In response to Re: libpq: PQgetCopyData() and allocation overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Interested, yes.  But there may be reasons not to do that.  Last time I looked the binary format wasn't documented.

Anyway, I tried re-implementing pqGetCopyData3() using the callback.  Wasn't hard, but I did have to add a way for the callback to return an error.  Kept it pretty dumb for now, hoping a sensible rule will become obvious later.

Saw no obvious performance impact, so that's good.


Jeroen

On Fri, 3 Mar 2023 at 19:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeroen Vermeulen <jtvjtv@gmail.com> writes:
> The printf() is just the simplest example that sprang to mind though.
> There may be other use-cases out there involving  libraries that require
> zero-terminated strings, and I figured an ability to set a sentinel could
> help those.

Well, since it won't help for binary COPY, I'm skeptical that this is
something we should cater to.  Anybody who's sufficiently worried about
performance to be trying to remove malloc/free cycles ought to be
interested in binary COPY as well.

                        regards, tom lane
Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: zstd compression for pg_dump
Next
From: Andrew Dunstan
Date:
Subject: Re: meson: Optionally disable installation of test modules