Re: Reducing connection overhead in pg_upgrade compat check phase

On Sat, 27 Jan 2024 at 09:10, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> 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.

With no update to the thread and the patch still not applying I'm
marking this as returned with feedback. Please feel free to resubmit
to the next CF when there is a new version of the patch.

Regards,
Vignesh