On Fri, 21 Aug 2026 at 09:29, Andy Fan <[email protected]> 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/
