From: | Sutou Kouhei <kou(at)clear-code(dot)com> |
---|---|
To: | sawada(dot)mshk(at)gmail(dot)com |
Cc: | andrew(at)dunslane(dot)net, michael(at)paquier(dot)xyz, zhjwpku(at)gmail(dot)com, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Make COPY format extendable: Extract COPY TO format implementations |
Date: | 2024-01-25 08:52:55 |
Message-ID: | 20240125.175255.1933853923727284252.kou@clear-code.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
In <CAD21AoALxEZz33NpcSk99ad_DT3A2oFNMa2KNjGBCMVFeCiUaA(at)mail(dot)gmail(dot)com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on Thu, 25 Jan 2024 13:36:03 +0900,
Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> I've experimented with a similar optimization for csv
> and text format; have different callbacks for text and csv format and
> remove "if (cstate->opts.csv_mode)" branches. I've attached a patch
> for that. Here are results:
>
> HEAD w/ 0001 patch + remove branches:
> binary 2824.502 ms
> text 2715.264 ms
> csv 2803.381 ms
>
> The numbers look better now. I'm not sure these are within a noise
> range but it might be worth considering having different callbacks for
> text and csv formats.
Wow! Interesting. I tried the approach before but I didn't
see any difference by the approach. But it may depend on my
environment.
I'll import the approach to the next patch set so that
others can try the approach easily.
Thanks,
--
kou
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2024-01-25 09:05:14 | RE: speed up a logical replica setup |
Previous Message | Sutou Kouhei | 2024-01-25 08:45:43 | Re: Make COPY format extendable: Extract COPY TO format implementations |