Re: refactor the CopyOneRowTo

On 31/07/2024 16:30, Junwang Zhao wrote:
> On Fri, Jul 5, 2024 at 12:26 AM jian he <jian(dot)universality(at)gmail(dot)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)