| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | GenBKI emits useless open;close for catalogs without rows |
| Date: | 2023-09-01 17:26:56 |
| Message-ID: | CAEze2Wh+uwUxKiDhYRBKuxin8A3nSuKf20LbSZwdmm1VKj_TWg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Whilst looking at PostgreSQL's bootstrapping process, I noticed that
postgres.bki contains quite a few occurrances of the pattern "open
$catname; close $catname".
I suppose this pattern isn't too expensive, but according to my
limited research a combined open+close cycle doens't do anything
meaningful, so it does waste some CPU cycles in the process.
The attached patch 1 removes the occurances of those combined
open/close statements in postgresql.bki. Locally it passes
check-world, so I assume that opening and closing a table is indeed
not required for initializing a data-less catalog during
bootstrapping.
A potential addition to the patch would to stop manually closing
relations: initdb and check-world succeed without manual 'close'
operations because the 'open' command auto-closes the previous open
relation (in boot_openrel). Testing also suggests that the last opened
relation apparently doesn't need closing - check-world succeeds
without issues (incl. with TAP enabled). That is therefore implemented
in attached patch 2 - it removes the 'close' syntax in its entirety.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)
| Attachment | Content-Type | Size |
|---|---|---|
| 0002-Remove-the-bki-close-command.patch | application/octet-stream | 3.2 KB |
| 0001-Stop-emitting-open-nodata-close-patterns-in-genbki.p.patch | application/octet-stream | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-09-01 17:31:43 | Re: Adding a pg_get_owned_sequence function? |
| Previous Message | Nathan Bossart | 2023-09-01 17:05:46 | Re: Inefficiency in parallel pg_restore with many tables |