From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Speeding up COPY TO for uuids and arrays |
Date: | 2024-02-17 20:24:33 |
Message-ID: | 20240217202433.b4f3hbvu45ntld7c@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-02-17 20:30:25 | Re: BUG #18348: Inconsistency with EXTRACT([field] from INTERVAL); |
Previous Message | Andres Freund | 2024-02-17 20:08:45 | Re: Add bump memory context type and use it for tuplesorts |