Re: Performance issue after migration from 9.4 to 15 - Mailing list pgsql-general

From Tom Lane
Subject Re: Performance issue after migration from 9.4 to 15
Date
Msg-id 143137.1681222135@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance issue after migration from 9.4 to 15  (David Rowley <dgrowleyml@gmail.com>)
Responses RE: Performance issue after migration from 9.4 to 15
List pgsql-general
David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 11 Apr 2023 at 23:03, Christian Schröder
> <Christian.Schroeder@solvians.com> wrote:
>> Particularly interesting are the sequential scans. In the old plan, we have node #21, which took 32 seconds. Almost
allof the time goes into actual I/O. In the new plan, the corresponding node is #34. It took 55 seconds, but less than
1second was actual I/O (because most of the data was already in memory). Why did this step still take about twice the
time?

> Perhaps your 15 server is under more load than 9.4 due to all
> concurrent plans being slower from bad statistics? Load averages might
> be a good indicator. (I assume the server is busy due to the "Workers
> Launched": 0)

I think the extra time is due to useless overhead from trying and failing
to parallelize: the leader has to do all the work, but there's probably
overhead added anyway.  9.4 of course knew nothing of parallelism.

My guess is that the OP is trying to run with a large number of backends
and has not raised the max number of parallel workers to match.  It
does look like the stats might need updating (since 9.4's rowcount
estimate is OK and 15's less so) but that is not why we see "Workers
planned: 2, Workers launched: 0".  Either provision enough parallel
workers to fix that, or disable parallelism.

            regards, tom lane



pgsql-general by date:

Previous
From: David Rowley
Date:
Subject: Re: Performance issue after migration from 9.4 to 15
Next
From: Christian Schröder
Date:
Subject: RE: Performance issue after migration from 9.4 to 15