Re: Performance degradation on concurrent COPY into a single relation in PG16.
От | Heikki Linnakangas |
---|---|
Тема | Re: Performance degradation on concurrent COPY into a single relation in PG16. |
Дата | |
Msg-id | d4a66eac-daa7-3a2a-cfd9-103023683b7e@iki.fi обсуждение исходный текст |
Ответ на | Re: Performance degradation on concurrent COPY into a single relation in PG16. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Performance degradation on concurrent COPY into a single relation in PG16.
|
Список | pgsql-hackers |
On 03/07/2023 05:59, Masahiko Sawada wrote: > On Mon, Jul 3, 2023 at 11:55 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> >> After further investigation, the performance degradation comes from >> calling posix_fallocate() (called via FileFallocate()) and pwritev() >> (called via FileZero) alternatively depending on how many blocks we >> extend by. And it happens only on the xfs filesystem. > > FYI, the attached simple C program proves the fact that calling > alternatively posix_fallocate() and pwrite() causes slow performance > on posix_fallocate(): > > $ gcc -o test test.c > $ time ./test test.1 1 > total 200000 > fallocate 200000 > filewrite 0 > > real 0m1.305s > user 0m0.050s > sys 0m1.255s > > $ time ./test test.2 2 > total 200000 > fallocate 100000 > filewrite 100000 > > real 1m29.222s > user 0m0.139s > sys 0m3.139s This must be highly dependent on the underlying OS and filesystem. I'm not seeing that effect on my laptop: /data$ time /tmp/test test.0 0 total 200000 fallocate 0 filewrite 200000 real 0m1.856s user 0m0.140s sys 0m1.688s /data$ time /tmp/test test.1 1 total 200000 fallocate 200000 filewrite 0 real 0m1.335s user 0m0.156s sys 0m1.179s /data$ time /tmp/test test.2 2 total 200000 fallocate 100000 filewrite 100000 real 0m2.159s user 0m0.165s sys 0m1.880s /data$ uname -a Linux heikkilaptop 6.0.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) x86_64 GNU/Linux /data is an nvme drive with ext4 filesystem. -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: