Re: Reducing connection overhead in pg_upgrade compat check phase

On Fri, 27 Oct 2023 at 18:50, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> 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
> outliers):
>
> 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.

CFBot shows that the patch does not apply anymore as in [1]:
=== Applying patches on top of PostgreSQL commit ID
55627ba2d334ce98e1f5916354c46472d414bda6 ===
=== applying patch
./v10-0001-pg_upgrade-run-all-data-type-checks-per-connecti.patch
patching file src/bin/pg_upgrade/check.c
Hunk #2 FAILED at 24.
...
1 out of 7 hunks FAILED -- saving rejects to file src/bin/pg_upgrade/check.c.rej

Please post an updated version for the same.

[1] - http://cfbot.cputube.org/patch_46_4200.log

Regards,
Vignesh