Re: pg_upgrade and schema complexity...

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_upgrade and schema complexity...
Date: 2023-06-03 01:06:15
Message-ID: 605d689c-7f3c-6ce6-1cfd-8a1511206dec@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/2/23 19:58, Adrian Klaver wrote:
> On 6/2/23 17:44, Ron wrote:
>> Ran into this when upgrading from 13.11 to 15.3...
>>
>> The pg_restore phase failed with "ERROR: out of shared memory", and
>> recommended that I increase max_locks_per_transaction. Doing so let the
>> process run to completion.
>>
>> It took 12.5 minutes to upgrade a 13GB instance.  Soon after, I upgraded
>> a 78GB cluster, and it only took 3.1 minutes.
>
> Where/how did you measure  those sizes?

Does it really matter?

START_SECS=$(date +"%s")
pg_upgrade ...
FINISH_SECS=$(date +"%s")
ET=`echo "scale=2;(${FINISH_SECS} - ${START_SECS})/60" | bc`
date +"%F %T pg_upgrade finished.  Elapsed time: ${ET} minutes."

(Text copied between air-gapped computers, so there might be errors.)

>>
>> (Both are VMs (same number of CPUs and RAM) connected to the same SAN.)
>>
>> A "pg_dump --schema-only" of the two systems shows that the
>> small-but-slow schema is 5.9M lines.
>
> Anything special you are doing in this cluster to create all those lines?

I do nothing; the schema is provided by the vendor.

>
> What is the line count for the other instance?

227K rows.

>>
>> Is this to be expected of such a huge schema?
>>

--
Born in Arizona, moved to Babylonia.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christophe Pettus 2023-06-03 01:08:31 Re: pg_upgrade and schema complexity...
Previous Message Adrian Klaver 2023-06-03 00:58:06 Re: pg_upgrade and schema complexity...