Re: Speeding up COPY TO for uuids and arrays

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Speeding up COPY TO for uuids and arrays
Дата
Msg-id 20240217202433.b4f3hbvu45ntld7c@awork3.anarazel.de
обсуждение исходный текст
Ответ на Speeding up COPY TO for uuids and arrays  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Speeding up COPY TO for uuids and arrays  (Michael Paquier <michael@paquier.xyz>)
Re: Speeding up COPY TO for uuids and arrays  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-hackers
Hi,

On 2024-02-17 17:48:23 +0100, Laurenz Albe wrote:
> - Patch 0001 speeds up pq_begintypsend with a custom macro.
>   That brought the binary copy down to 3.7 seconds, which is a
>   speed gain of 15%.

Nice win, but I think we can do a bit better than this. Certainly it shouldn't
be a macro, given the multiple evaluation risks.  I don't think we actually
need to zero those bytes, in fact that seems more likely to hide bugs than
prevent them.

I have an old patch series improving performance in this area. A big win is to
simply not allocate as much memory for a new stringinfo, when we already know
the upper bound, as we do in many of the send functions.


> - Patch 0001 speeds up uuid_out by avoiding the overhead of
>   a Stringinfo.  This brings text mode COPY to 19.4 seconds,
>   which is speed gain of 21%.

Nice!

I wonder if we should move the core part for converting to hex to numutils.c,
we already have code the for the inverse. There does seem to be further
optimization potential in the conversion, and that seems better done somewhere
central rather than one type's output function. OTOH, it might not be worth
it, given the need to add the dashes.


> - Patch 0003 speeds up array_out a bit by avoiding some zero
>   byte writes.  The measured speed gain is under 2%.

Makes sense.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Add bump memory context type and use it for tuplesorts
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements