On Wed, Sep 8, 2021 at 9:35 AM Robert Haas <robertmh...@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
