Re: suboverflowed subtransactions concurrency performance optimize
Simon Riggs <simon.riggs@enterprisedb.com>
From: Simon Riggs <simon.riggs@enterprisedb.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Pengchengliu <pengchengliu@tju.edu.cn>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-12-08T15:34:21Z
Lists: pgsql-hackers
On Wed, 1 Dec 2021 at 06:41, Andrey Borodin <x4mmm@yandex-team.ru> wrote: > > On review, I think it is also possible that we update subtrans ONLY if > > someone uses >PGPROC_MAX_CACHED_SUBXIDS. > > This would make subtrans much smaller and avoid one-entry-per-page > > which is a major source of cacheing. > > This would means some light changes in GetSnapshotData(). > > Let me know if that seems interesting also? > > I'm afraid of unexpected performance degradation. When the system runs fine, you provision a VM of some vCPU\RAM, and then some backend uses a little more than 64 subtransactions and all the system is stuck. Or will it affect only backend using more than 64 subtransactions? That is the objective: to isolate the effect to only those that overflow. It seems possible. -- Simon Riggs http://www.EnterpriseDB.com/
Commits
-
Revert "Add single-item cache when looking at topmost XID of a subtrans XID"
- b4529005fd38 15.0 landed
-
Add single-item cache when looking at topmost XID of a subtrans XID
- 06f5295af673 15.0 landed
-
Fix handling of partitioned index in RelationGetNumberOfBlocksInFork()
- 0d906b2c0b1f 15.0 cited