Re: refactor the CopyOneRowTo
От | Heikki Linnakangas |
---|---|
Тема | Re: refactor the CopyOneRowTo |
Дата | |
Msg-id | faafcae1-dd3c-4665-b36d-8711c4e26141@iki.fi обсуждение исходный текст |
Ответ на | Re: refactor the CopyOneRowTo (Junwang Zhao <zhjwpku@gmail.com>) |
Список | 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 по дате отправления: