Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade
От | Ranier Vilela |
---|---|
Тема | Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
Дата | |
Msg-id | CAEudQAptbRCeh08gaQKFdazOXPBqZh7UrjRcZ8fixyqkwrkUrA@mail.gmail.com обсуждение исходный текст |
Ответ на | use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade
Re: use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade |
Список | pgsql-hackers |
Em ter., 4 de jun. de 2024 às 16:39, Nathan Bossart <nathandbossart@gmail.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);
}
{
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
В списке pgsql-hackers по дате отправления: