Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9 - Mailing list pgsql-hackers

From Michael J. Baars
Subject Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9
Date
Msg-id CALudE+4+48bv3f+snVJJvfab=mSuWvScX_gsnYkeG=Xh9dKGTA@mail.gmail.com
Whole thread Raw
Responses Re: Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9
Re: Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9
List pgsql-hackers
Hello fellow PostgreSQL users and developers,

I installed a new Fedora release last week and ran into a peculiar problem:

Each night I need to run computations through about 70.000 rows and using release 16.3 that took about 4 hours to complete, but using release 16.9 the same computations now take about 8 hours to complete.

I've checked the unix sockets, inet sockets and the NVMe drive for deviations between the different kernels, but found none. Configuration files are exactly identical as well. Somewhere in between release 16.3 and release 16.9, changes must have been implemented that make the execution engine about two times slower than it was.

Two particular queries, that run about 70.000 times each night, gave the following results:

Query 1 over unix sockets:

release 16.3:
Time: 194.093 ms
Time: 169.714 ms
Time: 174.424 ms
Time: 170.285 ms

release 16.9:
Time: 281.554 ms
Time: 290.257 ms
Time: 290.886 ms
Time: 287.528 ms

Query 2 over unix sockets:

release 16.3:
Time: 132.500 ms
Time: 133.182 ms
Time: 134.511 ms
Time: 130.818 ms

release 16.9:
Time: 251.238 ms
Time: 247.749 ms
Time: 246.862 ms
Time: 248.541 ms

These differences add up to about 4 hours additional computation time each night. Apparently I have to scale down on the amount of work that can be done in one night.

Keep up the good work, but don't lose the big picture out of sight :) Hopefully this issue can be resolved quickly.

Kind regards,
Mischa.

Attachment

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: track generic and custom plans in pg_stat_statements
Next
From: Amit Kapila
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart