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

On Mon, Aug 7, 2023 at 3:16 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Wed, 2 Aug 2023 at 13:35, David Rowley <dgrowleyml(at)gmail(dot)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