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 1lmmGJ-0005SD-9T for pgsql-general@arkaria.postgresql.org; Fri, 28 May 2021 23:51:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lmmGG-0007Za-V8 for pgsql-general@arkaria.postgresql.org; Fri, 28 May 2021 23:51:28 +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 1lmmGG-0007ZR-F8 for pgsql-general@lists.postgresql.org; Fri, 28 May 2021 23:51:28 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lmmG9-0001eP-TR for pgsql-general@lists.postgresql.org; Fri, 28 May 2021 23:51:27 +0000 Received: by mail-ot1-x32d.google.com with SMTP id i12-20020a05683033ecb02903346fa0f74dso5059812otu.10 for ; Fri, 28 May 2021 16:51:21 -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=F3uL77XwMnuW6p7YY9a/L43n7ltl2pwYQo91E+98ufA=; b=PEoRHtZ4ii/1e3L8jHAirKa68Aw0Bs7ZnRm4/rvUYExYYi/0WmfJ9B8Mxnk8pteUCT bSVOU0JaU/fCGDKFrNrlTkd62v8w4Ph5QIgD8jV3ww8e99j6dUwGdP0L+m2UtkUWJ6d9 bmFoEMNk5I8kLmna5L9rJaACtoWsvzCjwSKt2Y9rRH053sZldUCmcqQNewbVlVHy+UzQ /+CviYU3YFZ1mksYMwD7tHvvcykpC3gZDiJXvP9aOdqR8pHqXdbfsAmHrt7DdcJrtWsq nWFWORURo0rdTHe4vvWlOgNh108wSiFbm8L/eeKXr1yMDrgwQjuggE28SLqNwCI7lztP 9W3Q== 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=F3uL77XwMnuW6p7YY9a/L43n7ltl2pwYQo91E+98ufA=; b=lUEl6RNKXl3+jYONxKnavEHT2YRVZdjMiaW0EZsvX2HA64vCWxfNj8+JINlHR78xIZ wKUKCIykIViGzb/gxRxhnshgWkNIceSCmGo9nbY5U/ThgA9kX+uhsW5DNQFTuRol/AO5 u0v+iwUf7cKv3Dba2PSlz7B3Q81yjKL1xevIYH8qP+GVKWrOK5J0q0nM7ysk3UD/DxZR RRw8HckeBA3GbMagHygz3opXmd4jtBe6E/i5dDbYzawT/1yZrrsDMmjr3WFYlyj0EJrv QP6VTgsnkNTwLMJDLiCe4i072/ihdueG6CvfJmhG1nvIUTbWAckDhM5l1pcoCKVj/fhy HUkw== X-Gm-Message-State: AOAM532Eyhr0UvcmEB0gFPWvYVbAIfB0kWNClV0Mohqtb/1AJeFlIkFW AnrHXV8dxrcLuj15kHvUgVROcZfqpvNRdg== X-Google-Smtp-Source: ABdhPJyqOGkPvrKHUVYeS3XnuBJGiO+1seXLh5d9b/34DH0I1ObYA4C/fKnOO0zi7nrOMU5ippwJWQ== X-Received: by 2002:a9d:27a4:: with SMTP id c33mr7716951otb.281.1622245879839; Fri, 28 May 2021 16:51:19 -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 n11sm1441015oom.1.2021.05.28.16.51.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 16:51:19 -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> <70edb767-6ba0-1065-2f74-f01440e3caea@gmail.com> From: Ron Message-ID: <2b7b9a25-e3c7-b980-a1e3-d21d8d91d34d@gmail.com> Date: Fri, 28 May 2021 18:51:18 -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: Content-Type: multipart/alternative; boundary="------------D93F7831D045ED2C6362A303" 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. --------------D93F7831D045ED2C6362A303 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/28/21 5:06 PM, Dean Gibson (DB Administrator) wrote: > On 2021-05-28 12:38, Ron wrote: >> 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. > > Just now did.  No change in EXPLAIN ANALYZE output. Did it run in less than 10 hours? -- Angular momentum makes the world go 'round. --------------D93F7831D045ED2C6362A303 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/28/21 5:06 PM, Dean Gibson (DB Administrator) wrote:
On 2021-05-28 12:38, Ron wrote:
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.

Just now did.  No change in EXPLAIN ANALYZE output.

Did it run in less than 10 hours?

--
Angular momentum makes the world go 'round.
--------------D93F7831D045ED2C6362A303--