Re: ProcArrayAdd/ProcArrayRemove in Prepared Transaction

On Fri, 21 Aug 2026 at 09:29, Andy Fan <zhihuifan1213(at)163(dot)com> wrote:
>
> Hi,
>
> Currently when we create a PreparedTransaction, we call ProcArrayAdd.
> Then when we FinishPreparedTransaction, we canl ProcArrayRemove. Both
> functions need do lots of memmove when holding a LW_EXCLUSIVE lock on
> ProcArrayLock. I guess this would be a common bottleneck on a
> PostgreSQL-based distributed database.
>
>
> Should we do something to improve this? The direct idea in my mind is we
> can cache N PGPROCs for prepared xact in ProcArray, it should be the
> number of concurrently *active* preapred transaction which maybe much
> less than max_prepared_xacts value, so it probably not too bad for
> ProcArray Scan. Then we can remove the both ProcArrayAdd and
> ProcArrayRemove. However besides we have to manage the PGPROC state
> carefully for these cached PGPROCs, another troubles is the PGPROC is
> bind to database and user, this make them hard to manage, any idea how
> to handle this?
>
> I want to PoC the above idea, but I hope some difference voice or the
> suggestion about the database/user stuff.

There's another thread on improving the performance of
ProcArrayAdd/Remove (primarily in non-huge-pages systems), which might
be of interest to you: [0].

As for a "hot" section for PGPROCS, one doesn't follow the current
dense array ordering rules: I think that could be interesting, but it
would trade GetSnapshotData's predictable linear memory accesses for
PROC registration efficiency. Benchmarks and measurements should show
whether that's a worthwhile trade-off; I think for it to be worthwhile
this unordered-by-procnumber section should probably remain very
small.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

[0]: https://commitfest.postgresql.org/patch/7139/