Re: Smoothing the subtrans performance catastrophe - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Smoothing the subtrans performance catastrophe
Date
Msg-id CA+TgmoYfkmS7aR2ZJv3WeV+hrj91w4b=3REDo4_zGQBBeuhxJQ@mail.gmail.com
Whole thread Raw
In response to Re: Smoothing the subtrans performance catastrophe  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Aug 3, 2022 at 4:14 PM Andres Freund <andres@anarazel.de> wrote:
> I don't think this scenario would fundamentally change - we already keep the
> set of subxids in backend local memory (e.g. either a dedicated
> TransactionStateData or an element in ->childXids) and in the locking table
> (via XactLockTableInsert()).

Sure....

> The problematic part isn't keeping "actually" running subxids in memory, but
> keeping subxids that might be "considered running" in memory (i.e. subxids
> that are considered running by an old snapshot in another backend).
>
> A hashtable just containing child->parent mapping for subxids doesn't actually
> need that much memory. It'd be approximately (2 * 4 bytes) * subxids *
> (2-fillfactor) or such? So maybe ~10MB for 1 milllion subxids?  Allocating
> that on-demand doesn't strike me as prohibitive.

I mean the worst case is ~2 bn, no?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Handle infinite recursion in logical replication setup
Next
From: Phil Florent
Date:
Subject: ERREUR: cache lookup failed for function 0 with PostgreSQL 15 beta 2, no error with PostgreSQL 14.4