Re: Reducing connection overhead in pg_upgrade compat check phase

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Reducing connection overhead in pg_upgrade compat check phase
Date: 2023-10-27 13:20:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Attached is a v10 rebase of this patch which had undergone significant bitrot
due to recent changes in the pg_upgrade check phase. This brings in the
changes into the proposed structure without changes to queries, with no
additional changes to the proposed functionality.

Testing with a completely empty v11 cluster fresh from initdb as the old
cluster shows a significant speedup (averaged over multiple runs, adjusted for

patched: 53.59ms (52.78ms, 52.49ms, 55.49ms)
master : 125.87ms (125.23 ms, 125.67ms, 126.67ms)

Using a similarly empty cluster from master as the old cluster shows a smaller
speedup, which is expected since many checks only run for older versions:

patched: 33.36ms (32.82ms, 33.78ms, 33.47ms)
master : 44.87ms (44.73ms, 44.90ms 44.99ms)

The latter case is still pretty interesting IMO since it can speed up testing
where every millisecond gained matters.

Daniel Gustafsson

Attachment Content-Type Size
v10-0001-pg_upgrade-run-all-data-type-checks-per-connecti.patch application/octet-stream 41.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2023-10-27 13:31:10 Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Previous Message Dean Rasheed 2023-10-27 13:05:21 Re: btree_gin: Incorrect leftmost interval value