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

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Performance degradation on concurrent COPY into a single relation in PG16.
Дата
Msg-id CAD21AoC0GvCEZbDreoAcj=i0LjNCQePQbh_cxCuBKezYgYwmTA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance degradation on concurrent COPY into a single relation in PG16.  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Performance degradation on concurrent COPY into a single relation in PG16.  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Mon, Aug 7, 2023 at 3:16 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Wed, 2 Aug 2023 at 13:35, David Rowley <dgrowleyml@gmail.com> wrote:
> > So, it looks like this item can be closed off.  I'll hold off from
> > doing that for a few days just in case anyone else wants to give
> > feedback or test themselves.
>
> Alright, closed.

IIUC the problem with multiple concurrent COPY is not resolved yet.
I've run the same benchmark that I used for the first report:

* PG15 (cb2ae5741f)
 nclients = 1, execution time = 15.213
 nclients = 2, execution time = 9.470
 nclients = 4, execution time = 6.508
 nclients = 8, execution time = 4.526
 nclients = 16, execution time = 3.788
 nclients = 32, execution time = 3.837
 nclients = 64, execution time = 4.286
 nclients = 128, execution time = 4.388
 nclients = 256, execution time = 4.333

* PG16 (67a007dc0c)
 nclients = 1, execution time = 14.494
 nclients = 2, execution time = 12.962
 nclients = 4, execution time = 17.757
 nclients = 8, execution time = 10.865
 nclients = 16, execution time = 7.371
 nclients = 32, execution time = 4.929
 nclients = 64, execution time = 2.212
 nclients = 128, execution time = 2.020
 nclients = 256, execution time = 2.196

The result of nclients = 1 became better thanks to recent fixes, but
there still seems to be the performance regression at nclient = 2~16
(on RHEL 8 and 9). Andres reported[1] that after changing
MAX_BUFFERED_TUPLES to 5000 the numbers became a lot better but it
would not be the solution, as he mentioned.

Regards,

[1] https://www.postgresql.org/message-id/20230711185159.v2j5vnyrtodnwhgz%40awork3.anarazel.de

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



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

Предыдущее
От: Alexander Pyhalov
Дата:
Сообщение: postgres_fdw could support row comparison pushdown
Следующее
От: Amit Langote
Дата:
Сообщение: Re: initial pruning in parallel append