Re: Postgres db Update to Version 15

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: "Ritthaler, Axel" <axel(dot)ritthaler(at)sap(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Hambrecht, Felix" <felix(dot)hambrecht(at)sap(dot)com>
Subject: Re: Postgres db Update to Version 15
Date: 2023-12-11 02:32:06
Message-ID: CAApHDvp5B9K72KX59FMwEg5K6np+Ay8eXuTHRUa-f6R_vaFLyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 10 Dec 2023 at 04:10, Ritthaler, Axel <axel(dot)ritthaler(at)sap(dot)com> wrote:
> The Root Cause of this behavior, as aligned with AWS RDS Support, has been a new feature-set coding (parallel_feature_query) with Postgres Version 15, that shows a different behavior due to related parameter (max_parallel_workers_per_gather).

What is parallel_feature_query? No version of PostgreSQL has a
setting by that name.

> Remaining question now is, what has to be done to move related Live-Landscapes back to the default parameter value (2) without creating the same impact again.

You'll need to identify the query or queries causing the problem.
We've likely made many more query shapes parallelizable in PG15
compared to PG11. So it does not seem unusual that PG15 will be able
to paralleize more of your queries than what PG11 could do. That
could lead to parallel plans not getting the workers they desire due
to workers being busy with other queries.

> What is your suggestion and recommended way-forward to enable parallel-worker setup again ?

Identify the queries causing the problem. Then determine if the plan
has changed since PG11. You can then check all the release notes
starting with PG12 to see if anything is mentioned about why the plan
might have changed. e.g. something in the query is parallelizable in
this version that wasn't in PG11.

One thing to keep in mind is that PostgreSQL does not opt to
parallelize the cheapest serial plan. It will attempt to find the
cheapest plan with or without parallel workers. The difference here
is that it's optimized for speed rather than resource usage. I'm not
sure if this is a factor in your issue, but it may be something to
keep in mind while investigating.

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2023-12-11 02:40:55 Re: Assert failure on 'list_member_ptr(rel->joininfo, restrictinfo)'
Previous Message Richard Guo 2023-12-11 02:31:14 Re: Assert failure on 'list_member_ptr(rel->joininfo, restrictinfo)'