Re: Init connection time grows quadratically

Hi,

On 2026-09-09 15:04:53 +0200, Matthias van de Meent wrote:
> From a62922a732b261ccfe5c7623aa4fe0e9b18c4aeb Mon Sep 17 00:00:00 2001
> From: Maksim Melnikov <m(dot)melnikov(at)postgrespro(dot)ru>
> Date: Tue, 18 Nov 2025 17:20:09 +0300
> Subject: [PATCH v5] This patch reduce connection init/close time.
>
> ProcArrayRemove/ProcArrayAdd are expensive in terms of accessing pgxactoff
> field in PGPROC, because its are placed on different pages and it the
> reason of page_faults occurence. Now one of the use case with pgxactoff
> is iteration with gaps over PGPROCs and read/write pgxactoff, PGPROC
> allocate ~1KB and it quite enough to have page_faults in case of such
> accessing.
>
> So we placed all pgxactoff in the separate array pgxactoffs to have adjacent
> pages for them all. Indexes in allProcs aligned with pgxactoffs array, so
> the Nth element in pgxactoffs refer to Nth PGPROC.
>
> Eventually it helps to avoid extra page_faults and reduce connection
> init/close time. The main benefit is seen on configurations without huge
> pages.

Maybe I am just missing something, but is this ever a benefit outside of
completely arbitrary scenarios? Who has >= 8k concurrent connections doing
nothing but connecting/disconnecting? Even if one were to agree that it's
useful to optimize large huge_pages=off workloads, surely that's an absurd
enough workload that nobody cares?

This isn't entirely free, needing to look at a separate cachelines that are
frequently modified (and thus commonly won't be in the cpu-local cache), in
reasonably common codepaths like ProcArrayEndTransactionInternal(),
TransactionIdIsInProgress(), GetSnapshotData() is far from free.

Greetings,

Andres Freund