From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
Date: | 2024-06-05 16:47:09 |
Message-ID: | CAEudQAptbRCeh08gaQKFdazOXPBqZh7UrjRcZ8fixyqkwrkUrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em ter., 4 de jun. de 2024 às 16:39, Nathan Bossart <
nathandbossart(at)gmail(dot)com> escreveu:
> I noticed that the "Restoring database schemas in the new cluster" part of
> pg_upgrade can take a while if you have many databases, so I experimented
> with a couple different settings to see if there are any easy ways to speed
> it up. The FILE_COPY strategy for CREATE DATABASE helped quite
> significantly on my laptop. For ~3k empty databases, this step went from
> ~100 seconds to ~30 seconds with the attached patch. I see commit ad43a41
> made a similar change for initdb, so there might even be an argument for
> back-patching this to v15 (where STRATEGY was introduced). One thing I
> still need to verify is that this doesn't harm anything when there are lots
> of objects in the databases, i.e., more WAL generated during many
> concurrent CREATE-DATABASE-induced checkpoints.
>
> Thoughts?
>
Why not use it too, if not binary_upgrade?
else
{
appendPQExpBuffer(creaQry, "CREATE DATABASE %s WITH TEMPLATE = template0
STRATEGY = FILE_COPY",
qdatname);
}
It seems to me that it also improves in any use.
best regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-06-05 17:07:58 | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
Previous Message | Nathan Bossart | 2024-06-05 16:37:54 | Re: small pg_dump code cleanup |