From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>, Andrew Zakharov <Andrew898(at)mail(dot)ru>, pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: performance degredation after upgrade from 9.6 to 12 |
Date: | 2019-12-03 21:13:21 |
Message-ID: | 20191203211321.kqqhjo3ey7m4mrgs@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-performance |
Hi,
On 2019-11-24 15:50:20 -0500, Jeff Janes wrote:
> OK, but do you agree that a 15% slow down is more realistic than 3 fold
> one? Or are you still getting 3 fold slow down with more careful testing
> and over a wide variety of queries?
>
> I find that the main regression (about 15%) in your example occurs in major
> version 10, at the following commit:
Huh, that's somewhat surprising. <5% I can see - there were some
tradeoffs to be made, and some performance issues to be worked around,
but 15% seems large. Is this with assertions enabled? Optimized?
> I also tested the same example, only 100 times
> more rows, and still see the regression at about 16%. This is a major
> infrastructure change patch which has been extensively built on since then,
> the chances of reverting it are very small. It is making an omelette, and
> your example is one of the eggs that got broken.
Yea, there's zero chance of a revert.
> Performance changes in a large body of queries are usually not all due to
> the same thing. Are you a position to custom compile your own PostgreSQL?
> It would be nice to test this commit against the one before it, and see how
> much of the change in your real queries is explained by this one thing (or
> whether any of it is)
In particular, artificial queries will often show bottlenecks that are
not releveant in practice...
> commit b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755
> Author: Andres Freund <andres(at)anarazel(dot)de>
> Date: Tue Mar 14 15:45:36 2017 -0700
>
> Faster expression evaluation and targetlist projection.
>
> It is disappointing that this made this case slower rather than faster, and
> that the "future work" alluded to either hasn't happened, or wasn't
> effective for this example.
I wonder if the improvements in
https://www.postgresql.org/message-id/20191023163849.sosqbfs5yenocez3%40alap3.anarazel.de
would at least partially address this.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Jorge Gustavo Rocha | 2019-12-03 22:29:04 | Help to get pgadmin4 running agains on Ubuntu v4.15 |
Previous Message | Tom Lane | 2019-12-03 16:10:41 | Re: Should I care about this error "failed to link /usr/bin/psql [...] exists and it is not a symlink"? |
From | Date | Subject | |
---|---|---|---|
Next Message | Lars Aksel Opsahl | 2019-12-05 12:10:42 | How to run in parallel in Postgres |
Previous Message | Michael Lewis | 2019-12-03 18:58:02 | Re: Make recently inserted/updated records available in the buffer/cache |