Re: pg_upgrade and schema complexity...
От | Ron |
---|---|
Тема | Re: pg_upgrade and schema complexity... |
Дата | |
Msg-id | 605d689c-7f3c-6ce6-1cfd-8a1511206dec@gmail.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade and schema complexity... (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: pg_upgrade and schema complexity...
|
Список | 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.
В списке pgsql-general по дате отправления: