Re: Smoothing the subtrans performance catastrophe

On Wed, Aug 3, 2022 at 4:14 PM Andres Freund <andres(at)anarazel(dot)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