On Nov 7, 2024, at 9:27 PM, Andrei Lepikhov wrote:
> Postgres didn't want Materialize in this example because of the low
> estimation on its outer subquery. AFAIC, by increasing the *_page_cost's
> value, you added extra weight to the inner subquery and shifted the decision
> to use materialisa
On 11/8/24 09:45, Ed Sabol wrote:
On Nov 7, 2024, at 9:27 PM, Andrei Lepikhov wrote:
Postgres didn't want Materialize in this example because of the low estimation on its outer subquery. AFAIC, by increasing the *_page_cost's value, you added extra weight to the inner subquery
What kind of ext
On 11/8/24 08:21, Ed Sabol wrote:
On Nov 7, 2024, at 5:18 PM, David Rowley wrote:
It's impossible to say with the given information. You didn't mention
which version you upgraded from to start with.
Sorry, 15.6 to 15.7 to 15.8, but we weren't on 15.7 for very long before 15.8.
You can set r
On Nov 7, 2024, at 5:18 PM, David Rowley wrote:
> It's impossible to say with the given information. You didn't mention
> which version you upgraded from to start with.
Sorry, 15.6 to 15.7 to 15.8, but we weren't on 15.7 for very long before 15.8.
> You can set random_page_cost for just the sess
On Fri, 8 Nov 2024 at 10:54, Ed Sabol wrote:
> The good news is that, after some research and experimentation, I was able to
> fix this performance degradation by setting random_page_cost = 2.0. We've
> always used the default values for seq_page_cost and random_page_cost (1.0
> and 4.0, respec
Hello! I have a database installation that goes back about 10 years. It's using
a hardware RAID consisting of enterprise-caliber spinning drives. I upgraded
the installation to PostgreSQL 15.8 a couple months ago.
Sometime after that, it was noticed that one of our application's queries
suffere
