Re: Smoothing the subtrans performance catastrophe

On Wed, Aug 3, 2022 at 3:18 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> In contrast to e.g. clog or multixact we don't need to access a lot of old
> While we can't put a useful hard cap on the number of potential subtrans
> entries (we can only throw subxid->parent mappings away once no existing
> snapshot might need them), saying that there can't be more subxids "considered
> running" at a time than can fit in memory doesn't seem like a particularly
> problematic restriction.

That sounds really problematic to me, unless I misunderstand what
you're proposing. Say I have a plpgsql containing a FOR loop which in
turn contains an EXCEPTION block which in turn does DML. Right now,
that loop could iterate millions of times and everything would still
work. Sure, there might be performance impacts depending on what else
is happening on the system, but it might also be totally fine. IIUC,
you'd like to make that case fail outright. I think that's a
non-starter.

I don't know whether Simon's ideas here are amazingly good, utterly
terrible, or something in between, but I think we can evaluate the
patch actually submitted rather than propose a complete redesign of
the entire mechanism - especially one that seems like it would break
stuff that currently works.

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