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 69bdf766-7871-8dc9-f074-38b0c3e16fc5@mailpen.com
Whole thread Raw
In response to Re: AWS forcing PG upgrade from v9.6 a disaster  (Jan Wieck <jan@wi3ck.info>)
List pgsql-performance
On 2021-05-28 13:23, Jan Wieck wrote:
On 5/28/21 2:48 PM, Dean Gibson (DB Administrator) wrote:

What sticks out for me are these two scans, which balloon from 50-60 heap fetches to 1.5M each.

                      ->  Nested Loop  (cost=0.29..0.68 rows=1 width=7) (actual time=0.003..0.004 rows=1 loops=1487153)
                            Join Filter: ("_IsoCountry".iso_alpha2 = "_Territory".country_id)
                            Rows Removed by Join Filter: 0
                            ->  Index Only Scan using "_IsoCountry_iso_alpha2_key" on "_IsoCountry"  (cost=0.14..0.38 rows=1 width=3) (actual time=0.001..0.002 rows=1 loops=1487153)
                                  Index Cond: (iso_alpha2 = "_GovtRegion".country_id)
                                  Heap Fetches: 1487153
                            ->  Index Only Scan using "_Territory_pkey" on "_Territory"  (cost=0.14..0.29 rows=1 width=7) (actual time=0.001..0.001 rows=1 loops=1487153)
                                  Index Cond: (territory_id = "_GovtRegion".territory_id)
                                  Heap Fetches: 1550706

How did you load the database? pg_dump -> psql/pg_restore?

If so, did you perform a VACUUM FREEZE after the load?

Regards, Jan

It was RDS's "upgrade in place".  According to the PostgreSQL site, for v9.4 & v12: "Aggressive freezing is always performed when the table is rewritten, so this option is redundant when FULL is specified."

I did a VACUUM FULL.

pgsql-performance by date:

Previous
From: Bob Lunney
Date:
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster
Next
From: Jan Wieck
Date:
Subject: Re: AWS forcing PG upgrade from v9.6 a disaster