Re: AWS forcing PG upgrade from v9.6 a disaster - Mailing list pgsql-performance

From Dean Gibson (DB Administrator)
Subject Re: AWS forcing PG upgrade from v9.6 a disaster
Date
Msg-id 5463af86-9007-1094-78bf-18e54c60edaf@mailpen.com
Whole thread Raw
In response to Re: AWS forcing PG upgrade from v9.6 a disaster  (Christophe Pettus <xof@thebuild.com>)
Responses Re: AWS forcing PG upgrade from v9.6 a disaster
List pgsql-performance
On 2021-05-30 20:41, Christophe Pettus wrote:
On May 30, 2021, at 20:07, Dean Gibson (DB Administrator) <postgresql@mailpen.com> wrote:
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.
If, rather than a subquery, you explicitly called out the join criteria with ON, did it have the same performance benefit?

I thought that having a "USING" clause, was semantically equivalent to an "ON" clause with the equalities explicitly stated.  So no, I didn't try that.

The matching that occurred is exactly what I wanted.  I just didn't want the performance impact.

pgsql-performance by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster
Next
From: Tom Lane
Date:
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster