Re: v17 vs v16 performance comparison

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: v17 vs v16 performance comparison
Date: 2024-09-03 05:00:00
Message-ID: 8d6053a4-5999-b479-0d57-538200dda973@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Thomas,

02.08.2024 12:00, Alexander Lakhin wrote:

>
>>
>>>
>>> I had payed attention to:
>>> Best pg-src-17--.* worse than pg-src-16--.* by 57.9 percents (225.11 > 142.52): pg_tpcds.query15
>>> Average pg-src-17--.* worse than pg-src-16--.* by 55.5 percents (230.57 > 148.29): pg_tpcds.query15
>>> in May, performed `git bisect` for this degradation, that led me to commit
>>> b7b0f3f27 [1].
>>>
>>> This time I bisected the following anomaly:
>>> Best pg-src-17--.* worse than pg-src-16--.* by 23.6 percents (192.25 > 155.58): pg_tpcds.query21
>>> Average pg-src-17--.* worse than pg-src-16--.* by 25.1 percents (196.19 > 156.85): pg_tpcds.query21
>>> and to my surprise I got "b7b0f3f27 is the first bad commit".
>>>
>>> Moreover, bisecting of another anomaly:
>>> Best pg-src-17--.* worse than pg-src-16--.* by 24.2 percents (24269.21 > 19539.89): pg_tpcds.query72
>>> Average pg-src-17--.* worse than pg-src-16--.* by 24.2 percents (24517.66 > 19740.12): pg_tpcds.query72
>>> pointed at the same commit again.
>>>
>>> ...
>>>
>>> But beside that, I've found a separate regression. Bisecting for this degradation:
>>> Best pg-src-17--.* worse than pg-src-16--.* by 105.0 percents (356.63 > 173.96): s64da_tpcds.query95
>>> Average pg-src-17--.* worse than pg-src-16--.* by 105.2 percents (357.79 > 174.38): s64da_tpcds.query95
>>> pointed at f7816aec2.
>>
>
> Meanwhile I've bisected another degradation:
> Best pg-src-17--.* worse than pg-src-16--.* by 11.3 percents (7.17 > 6.44): job.query6f
> and came to the commit b7b0f3f27 again.

Now that the unfairness in all-cached parallel seq scan eliminated (with
3ed3683618),  I've re-run the same performance tests and got new results
(please see attached). As we can see, the aforementioned pg_tpcds.query72
got better:
              2024-05-15  2024-07-30 2024-09-03
pg-src-16--1   20492.58    19669.34    19913.32
pg-src-17--1   25286.10    24269.21    20654.95
pg-src-16--2   20769.88    19539.89    20429.72
pg-src-17--2   25771.90    24530.51    21244.92
pg-src-17--3   25978.55    24753.25    20904.09
pg-src-16--3   20943.10    20011.13    20086.61

We can also see the improvement of pg_tpcds.query16, but not on all runs:
              2024-05-15  2024-07-30 2024-09-03
pg-src-16--1     105.36       94.31       97.74
pg-src-17--1     145.74      145.53      145.51
pg-src-16--2     101.82       98.36       96.63
pg-src-17--2     140.07      146.90       96.93
pg-src-17--3     154.89      148.11      106.18
pg-src-16--3     101.03      100.94       93.44

So it looks like now we see the same instability, that we observed before
([1]).

Unfortunately, the troublesome tpcds.query15 hasn't produced good numbers
this time too:
              2024-05-15  2024-07-30 2024-09-03
pg-src-16--1     153.41      142.52      142.54
pg-src-17--1     229.84      225.11      212.51
pg-src-16--2     153.47      150.13      149.37
pg-src-17--2     236.34      227.15      232.73
pg-src-17--3     236.43      239.46      233.77
pg-src-16--3     151.03      152.23      144.90

From a bird's eye view, new v17-vs-v16 comparison has only 87 "worse",
while the previous one had 115 (it requires deeper analysis, of course, but
still...).

[1] https://www.postgresql.org/message-id/d1fb5c09-dd03-2540-9ec2-86dbfdfa2c65%40gmail.com

Best regards,
Alexander

Attachment Content-Type Size
benchmark-results-240903.html text/html 48.2 KB
v17-vs-v16-comparison-240903.txt text/plain 26.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2024-09-03 05:00:54 Re: Add callback in pgstats for backend initialization
Previous Message jian he 2024-09-03 04:59:37 Re: Virtual generated columns