Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Дата
Msg-id CAEudQAopRdKOMLxDgr7GjmQbNUYTd_aVPR7b66ABrf5o_OnFYg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Ответы Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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
Вложения

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

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Re: adding status for COPY progress report
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL Limits: maximum number of columns in SELECT result