On Wed, Sep 8, 2021 at 9:35 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I'm not trying to argue for slimming down your patches to a size that
> is so small that they no longer work.
I was just explaining how the "eager physical rollback by pruning" thing works.
> However, I *am* arguing that, like bottom-up index deletion and the
> emergency vacuum mechanism, this change sounds like something that
> could *easily* have unforeseen consequences. And therefore a lot of
> caution is needed.
I agree that a lot of caution is needed. One can justify aggressive
intervention when the likely alternative is a severe and irreversible
adverse event, like a version-driven page split. On the other hand we
really should be very conservative when that isn't what we see.
Context is very important.
> And part of that caution is not changing more
> things at the same time than is really necessary. And that it's worth
> thinking *hard* about how much change is *really* necessary.
For the record bottom-up index deletion had very little code in the
grand scheme of things. Without documentation changes and comments it
is probably less than 1000 lines of C. And the emergency mechanism
(considered separately from the refactoring work) had very little
code. So I don't know what you mean about changing lots of things all
together at once. Huge big-bang style patches really aren't my style
at all. Don't expect that to change.
> It's very easy to convince oneself that everything is connected to
> everything else and therefore we have to change a lot of things all at
> once, but that's often not true.
There is compelling empirical evidence for my "chain of events"
explanation. You can make things much better for BenchmarkSQL on the
master branch today, either by artificially disabling the FSM
altogether (which hurts a little but helps a lot), *or* by configuring
the benchmark to not abort transactions in the first place (which
effectively simulates eager physical rollback of aborted xacts).
I don't want to change very much. Despite everything I've said, I
think it's true that the system does the right thing in most
situations -- even with BenchmarkSQL/TPC-C! I just find it useful to
focus on the exceptions, the cases where the system clearly does the
wrong thing.
--
Peter Geoghegan