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" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster
Date: 2021-05-31 04:23:43
Message-ID: 5463af86-9007-1094-78bf-18e54c60edaf@mailpen.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On 2021-05-30 20:41, Christophe Pettus wrote:
> On May 30, 2021, at 20:07, Dean Gibson (DB Administrator)
> <postgresql(at)mailpen(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-31 04:44:27 Re: AWS forcing PG upgrade from v9.6 a disaster
Previous Message Tom Lane 2021-05-31 04:05:12 Re: Multiple hosts in connection string failed to failover in non-hot standby mode

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2021-05-31 04:44:27 Re: AWS forcing PG upgrade from v9.6 a disaster
Previous Message Christophe Pettus 2021-05-31 03:41:28 Re: AWS forcing PG upgrade from v9.6 a disaster