| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> | 
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | use CREATE DATABASE STRATEGY = FILE_COPY in pg_upgrade | 
| Date: | 2024-06-04 19:39:23 | 
| Message-ID: | Zl9ta3FtgdjizkJ5@nathan | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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?
-- 
nathan
| Attachment | Content-Type | Size | 
|---|---|---|
| use_file_copy_for_pg_upgrade.patch | text/plain | 515 bytes | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-06-04 20:13:12 | Re: Unexpected results from CALL and AUTOCOMMIT=off | 
| Previous Message | Tom Lane | 2024-06-04 18:28:43 | Re: Unexpected results from CALL and AUTOCOMMIT=off |