Re: refactor the CopyOneRowTo - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: refactor the CopyOneRowTo
Date
Msg-id faafcae1-dd3c-4665-b36d-8711c4e26141@iki.fi
Whole thread Raw
In response to Re: refactor the CopyOneRowTo  (Junwang Zhao <zhjwpku@gmail.com>)
List 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)




pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: [PATCH] Add get_bytes() and set_bytes() functions
Next
From: Tomas Vondra
Date:
Subject: Re: Drop database command will raise "wrong tuple length" if pg_database tuple contains toast attribute.