Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmiJ7-00069K-6n for pgsql-general@arkaria.postgresql.org; Fri, 28 May 2021 19:38:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lmiJ6-0003eg-6W for pgsql-general@arkaria.postgresql.org; Fri, 28 May 2021 19:38:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmiJ5-0003eY-U1 for pgsql-general@lists.postgresql.org; Fri, 28 May 2021 19:38:07 +0000 Received: from mail-oo1-xc34.google.com ([2607:f8b0:4864:20::c34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lmiJ3-00089y-M9 for pgsql-general@lists.postgresql.org; Fri, 28 May 2021 19:38:06 +0000 Received: by mail-oo1-xc34.google.com with SMTP id e27-20020a056820061bb029020da48eed5cso1191108oow.10 for ; Fri, 28 May 2021 12:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=9/BWy47FHdZQ72SUjTK44yA2BcRnkYsAzODZiHFXrEI=; b=IadK8dRCR0BN5DQj8jFMigGFqP8N3TSkyUdCTIDB2ci20xS7vK+SQAM5ELOPfyGjGT FtifR4Kv7cp0hr+rLSr2hj7XRPvnYPtIo3+Vut+e91Mmld3PjOSDQbREohj0ycOijoWZ Y7DosZ6nRM6PhdSQol/HYU0qtIxCMWJLcjrssn9xRGMrBaerXm+vb+IV8fD6okJrMcmJ TIPKREfrZpKGJEZDzmrVqAYnKfhEMCKcEWHo3i9ULDSsiS+ni6cfQrcXvl4ZC4kPW09/ xbW3TSFWqIlw8t6ObJkAbzP4YW49tumN76/rvQcSax60iofqKFq4XHNhjjUrhESqOnDE 1iJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=9/BWy47FHdZQ72SUjTK44yA2BcRnkYsAzODZiHFXrEI=; b=t8MztOdALbQ0/Hu4OhBHY+bZI+cNkfFCy0S7M1Js+o8mi5hL3EgINLKzKIphaL2gZl fTtFnrtk+DZcUrZR7Jh44ViH4Lz377xOGbC8moVbTlBluigiEHvuhGiy2rtxtsfeomz/ oimhBggogxbb6xLS+9p6F2iBFKaXuP7dSTHQ8EOV82nCG7SgZ6pMoFxGbQTJef+TlWxd qLPCj69LykMm0vcG8zga4HpownHv2jkI04gUTUhMQK5GZ2XOnqWRDvlHTidd91Pc1aUL eiB8aY2QDZOPK7a4YR5tyzfmRZ8v0WavSQNbgBY0hJWiwFhrz7+nmTAX6wUhGDP0ydgU R2jg== X-Gm-Message-State: AOAM533pXH7Twk6XJm3VLDFs5K2tzfltMfeca0YsBGUUVpkGg1KQnhgR yO+fjudx9DHCvW3lJD/Nc07jHNwNWuzq9A== X-Google-Smtp-Source: ABdhPJx875XKL57fzmFBbJLNO3FPYAExYkgZBeb0Qk1NQiSDye/hCyC6dgezQVQOMQ2k5gnnY0utFA== X-Received: by 2002:a4a:6765:: with SMTP id j37mr3087539oof.57.1622230684366; Fri, 28 May 2021 12:38:04 -0700 (PDT) Received: from [192.168.88.10] (ip174-67-141-204.no.no.cox.net. [174.67.141.204]) by smtp.googlemail.com with ESMTPSA id c18sm1316474otm.1.2021.05.28.12.38.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 12:38:03 -0700 (PDT) Subject: Re: AWS forcing PG upgrade from v9.6 a disaster To: pgsql-general@lists.postgresql.org References: <3fa6fd38-1f92-98ab-0055-3e0eb7e4e772@ultimeth.com> <2a1b34f4-73d4-585b-f4fc-3bd9b9ba248e@aklaver.com> <88255b75-e7e3-b29c-0e75-f989ea320570@mailpen.com> From: Ron Message-ID: <70edb767-6ba0-1065-2f74-f01440e3caea@gmail.com> Date: Fri, 28 May 2021 14:38:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <88255b75-e7e3-b29c-0e75-f989ea320570@mailpen.com> Content-Type: multipart/alternative; boundary="------------200A3325192972F716091A1F" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------200A3325192972F716091A1F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/28/21 1:40 PM, Dean Gibson (DB Administrator) wrote: > On 2021-05-28 08:12, Adrian Klaver wrote: >> On 5/27/21 8:41 PM, Dean Gibson (DB Administrator) wrote: >>> I started to use PostgreSQL v7.3 in 2003 on my home Linux systems (4 at >>> one point), gradually moving to v9.0 w/ replication in 2010.  In 2017 I >>> moved my 20GB database to AWS/RDS, gradually upgrading to v9.6, & was >>> entirely satisfied with the result. >>> >>> In March of this year, AWS announced that v9.6 was nearing end of >>> support, & AWS would forcibly upgrade everyone to v12 on January 22, >>> 2022, if users did not perform the upgrade earlier.  My first attempt >>> was successful as far as the upgrade itself, but complex queries that >>> normally ran in a couple of seconds on v9.x, were taking minutes in v12. >> >> Did you run a plain >> ANALYZE(https://www.postgresql.org/docs/12/sql-analyze.html) on the >> tables in the new install? > > After each upgrade (to 10, 11, 12, & 13), I did a "VACUUM FULL ANALYZE".  > On 10 through 12, it took about 45 minutes & significant CPU activity, & > temporarily doubled the size of the disk space required.  As you know, > that disk space is not shrinkable under AWS's RDS.  On v13, it took 10 > hours with limited CPU activity, & actually slightly less disk space > required. Under normal conditions, VACUUM FULL is pointless on a freshly-loaded database; in RDS, it's *anti-useful*. That's why Adrian asked if you did a plain ANALYZE. -- Angular momentum makes the world go 'round. --------------200A3325192972F716091A1F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/28/21 1:40 PM, Dean Gibson (DB Administrator) wrote:
On 2021-05-28 08:12, Adrian Klaver wrote:
On 5/27/21 8:41 PM, Dean Gibson (DB Administrator) wrote:
I started to use PostgreSQL v7.3 in 2003 on my home Linux systems (4 at one point), gradually moving to v9.0 w/ replication in 2010.  In 2017 I moved my 20GB database to AWS/RDS, gradually upgrading to v9.6, & was entirely satisfied with the result.

In March of this year, AWS announced that v9.6 was nearing end of support, & AWS would forcibly upgrade everyone to v12 on January 22, 2022, if users did not perform the upgrade earlier.  My first attempt was successful as far as the upgrade itself, but complex queries that normally ran in a couple of seconds on v9.x, were taking minutes in v12.

Did you run a plain ANALYZE(https://www.postgresql.org/docs/12/sql-analyze.html) on the tables in the new install?

After each upgrade (to 10, 11, 12, & 13), I did a "VACUUM FULL ANALYZE".  On 10 through 12, it took about 45 minutes & significant CPU activity, & temporarily doubled the size of the disk space required.  As you know, that disk space is not shrinkable under AWS's RDS.  On v13, it took 10 hours with limited CPU activity, & actually slightly less disk space required.

Under normal conditions, VACUUM FULL is pointless on a freshly-loaded database; in RDS, it's anti-useful.

That's why Adrian asked if you did a plain ANALYZE.

--
Angular momentum makes the world go 'round.
--------------200A3325192972F716091A1F--