Re: suboverflowed subtransactions concurrency performance optimize

On Fri, 3 Dec 2021 at 06:27, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Tue, Nov 30, 2021 at 5:49 PM Simon Riggs
> <simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>
> > transam.c uses a single item cache to prevent thrashing from repeated
> > lookups, which reduces problems with shared access to SLRUs.
> > multitrans.c also has similar.
> >
> > I notice that subtrans. doesn't have this, but could easily do so.
> > Patch attached, which seems separate to other attempts at tuning.
>
> Yeah, this definitely makes sense.
>
> > 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?
>
> Do you mean to say avoid setting the sub-transactions parent if the
> number of sun-transactions is not crossing PGPROC_MAX_CACHED_SUBXIDS?

Yes.

This patch shows where I'm going, with changes in GetSnapshotData()
and XidInMVCCSnapshot() and XactLockTableWait().
Passes make check, but needs much more, so this is review-only at this
stage to give a flavour of what is intended.

(No where near replacing the subtrans module as I envisage as the
final outcome, meaning we don't need ExtendSUBTRANS()).

--
Simon Riggs http://www.EnterpriseDB.com/