From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: v17 vs v16 performance comparison |
Date: | 2024-08-02 09:00:00 |
Message-ID: | 4e14cc4f-edaf-0820-2bdf-db8dd0a9efab@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
01.08.2024 06:41, Tom Lane wrote:
>
>> 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.
> I'm not terribly concerned about that. The nature of planner changes
> like that is that some queries will get worse and some better, because
> the statistics and cost estimates we're dealing with are not perfect.
> It is probably worth drilling down into that test case to understand
> where the planner is going wrong, with an eye to future improvements;
> but I doubt it's something we need to address for v17.
Please find attached two plans for that query [1].
(I repeated the benchmark for f7816aec2 and f7816aec2~1 five times and
made sure that both plans are stable.)
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.
Best regards,
Alexander
Attachment | Content-Type | Size |
---|---|---|
0_95-06c70849f.txt | text/plain | 27.9 KB |
0_95-f7816aec2.txt | text/plain | 35.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | shveta malik | 2024-08-02 09:03:32 | Re: Logical Replication of sequences |
Previous Message | shveta malik | 2024-08-02 08:54:45 | Re: Logical Replication of sequences |