Re: Improving connection scalability (src/backend/storage/ipc/procarray.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Date
Msg-id CAEudQAopRdKOMLxDgr7GjmQbNUYTd_aVPR7b66ABrf5o_OnFYg@mail.gmail.com
Whole thread Raw
In response to Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
Em dom., 29 de mai. de 2022 às 17:10, Ranier Vilela <ranier.vf@gmail.com> escreveu:
Em dom., 29 de mai. de 2022 às 15:21, Andres Freund <andres@anarazel.de> escreveu:
On 2022-05-29 18:00:14 +0200, Tomas Vondra wrote:
> Also, there's the question of correctness, and I'd bet Andres is right
> getting snapshot without holding ProcArrayLock is busted.

Unless there's some actual analysis of this by Rainier, I'm just going to
ignore this thread going forward. It's pointless to invest time when
everything we say is just ignored.
Sorry, just not my intention to ignore this important point.
Of course, any performance gain is good, but robustness comes first.

As soon as I have some time.
I redid the benchmarks, with getting a snapshot with holding ProcArrayLock.

Average Results




Connections:         
tps headtps patchdiff
139196,308898539858,0207936661,711895100008101,69%
265050,864381965245,9852367195,1208548100,30%
591486,029835991862,9026528376,872816899995100,41%
10131318,0774955131547,1404573229,062961799995100,17%
50116531,2334144116687,0325522155,799137800001100,13%
10098969,465044998808,6778717-160,78717319999199,84%
20089514,523864989463,6196075-50,90425740000599,94%
30088426,361218388457,269515130,9082968000002100,03%
40088078,168691288338,2859163260,117225099995100,30%
50087791,162003988074,3418504283,179846500003100,32%
60087552,334339487930,8645184378,530178999994100,43%
100086538,377289586771,1946099232,817320400005100,27%
avg89204,408873191789420,4446318251981,0816042100,24%
 
For clients with 1 connections, the results are good.
But for clients with 100 and 200 connections, the results are not good.
I can't say why these two tests were so bad.
Because, 100 and 200 results, I'm not sure if this should go ahead, if it's worth the effort.

Attached the results files and calc plan.

regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: adding status for COPY progress report
Next
From: Tom Lane
Date:
Subject: Re: PostgreSQL Limits: maximum number of columns in SELECT result