Re: libpq: PQgetCopyData() and allocation overhead

Поиск
Список
Период
Сортировка
От Jeroen Vermeulen
Тема Re: libpq: PQgetCopyData() and allocation overhead
Дата
Msg-id CA+zULE7_7tLNiqiA4PZs5VQ9yzAxrNbSgfSBJxYN_q1bymo1Eg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: libpq: PQgetCopyData() and allocation overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: zstd compression for pg_dump
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: meson: Optionally disable installation of test modules