Re: AWS forcing PG upgrade from v9.6 a disaster

From: "Dean Gibson (DB Administrator)" <postgresql(at)mailpen(dot)com>
To: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster
Date: 2021-06-01 17:44:54
Message-ID: a38c45cf-3bbd-b43a-0f8a-11539c1c6dc1@mailpen.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On 2021-05-31 21:16, Justin Pryzby wrote:
>> Here's the FROM clause that bit me:
>>
>> FROM lic_en
>> JOIN govt_region USING (territory_id, country_id)
>> LEFT JOIN zip_code USING (territory_id, country_id, zip5)
>> LEFT JOIN "County" USING (territory_id, country_id, fips_county);
> I'm guessing that there's a dependency/correlation between territory/country/county, and that's probably related to a misestimate causing a bad plan.
>
>> The first two JOINs are not the problem, & are in fact retained in my solution. The problem is the third JOIN, where "fips_county" from "County" is actually matched with the corresponding field from the "zip_code" VIEW. Works fine, if you don't mind the performance impact in v10 & above. It has now been rewritten, to be a sub-query for an output field. Voila ! Back to sub-second query times.
> What version of 9.6.X were you upgrading *from* ?
>
> v9.6 added selectivity estimates based on FKs, so it's not surprising if there was a plan change migrating *to* v9.6.

I originally upgraded from 9.6.20 to v12.6.  When that (otherwise
successful) upgrade had performance problems, I upgraded the v9.6.20
copy to v9.6.21, & tried again, with the same result.

Interestingly, on v13.2 I have now run into another (similar)
performance issue.  I've solved it by setting the following to values I
used with v9.x:

join_collapse_limit & from_collapse_limit = 16

geqo_threshold = 32

I pretty sure I tried those settings (on v10 & above) with the earlier
performance problem, to no avail.  However, I now wonder what would have
been the result if I have doubled those values before re-architecting
some of my tables (moving from certain JOINs to specific sub-selects).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-01 17:46:05 Re: CALL versus procedures with output-only arguments
Previous Message Zhihong Yu 2021-06-01 17:32:59 return correct error code from pgtls_init

Browse pgsql-performance by date

  From Date Subject
Next Message Ayub Khan 2021-06-04 08:06:56 slow query with inline function on AWS RDS with RDS 24x large
Previous Message Justin Pryzby 2021-06-01 04:16:35 Re: AWS forcing PG upgrade from v9.6 a disaster