Re: refactor the CopyOneRowTo
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Junwang Zhao <zhjwpku@gmail.com>, jian he <jian.universality@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-16T11:05:50Z
Lists: pgsql-hackers
On 31/07/2024 16:30, Junwang Zhao wrote: > On Fri, Jul 5, 2024 at 12:26 AM jian he <jian.universality@gmail.com> wrote: >> overall less "if else" logic, >> also copy format don't change during copy, we don't need to check >> binary or nor for each datum value. Committed, thanks. For the archives: this code is in a very hot path during COPY TO, so I did some quick micro-benchmarking on my laptop. I used this: COPY (select 0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10,0,1,2,3,4,5,6,7,8,9,10 from generate_series(1, 1_000_000) g) TO '/dev/null'; and COPY (select 0 from generate_series(1, 1_000_000) g) TO '/dev/null'; to check the impact with few attributes and with many attributes. I repeated that a few times with \timing with and without the patch, and eyeballed the result. I also used 'perf' to check the fraction of CPU time spent in CopyOneRowTo. Conclusion: the patch has no performance impact. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Refactor CopyOneRowTo
- 3943da46bc54 18.0 landed