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).
