Re: Performance degradation on concurrent COPY into a single relation in PG16.

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Performance degradation on concurrent COPY into a single relation in PG16.
Дата
Msg-id CAApHDvp_qmfCW6UmTtz=oz3hD=B2YCAT64YU-nycim8H9tzKFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance degradation on concurrent COPY into a single relation in PG16.  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: Performance degradation on concurrent COPY into a single relation in PG16.  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
On Wed, 2 Aug 2023 at 07:38, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> Running the new test on slightly older Intel hardware (i9-9900K, gcc
> 11.3), I get the following:

Thanks for running those tests. I've now pushed the fastpath4.patch
after making a few adjustments to the header comments to mention the
new stuff that was added in v16.

> I don't know why HEAD and v16 aren't consistent, but it's seems to be
> quite reproducible, even though the numutils source is the same in
> both branches, and using gdb to dump the disassembly for
> pg_strtoint32_safe() shows that it's also the same.

I also see it's inconsistent, but the other way around. Here are some
fresh tests with master and REL_16_STABLE with the committed code and
the version directly prior to the commit:

master @ 3845577cb
latency average = 1575.879 ms

   6.79%  postgres          [.] pg_strtoint32_safe

master~1
latency average = 1968.004 ms

  14.28%  postgres          [.] pg_strtoint32_safe

REL_16_STABLE
latency average = 1735.163 ms

   6.04%  postgres          [.] pg_strtoint32_safe

REL_16_STABLE~1
latency average = 2188.186 ms

  13.83%  postgres          [.] pg_strtoint32_safe

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Faster "SET search_path"
Следующее
От: Masahiro Ikeda
Дата:
Сообщение: Re: Support to define custom wait events for extensions