On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs <simon.ri...@enterprisedb.com> wrote: > Definitely some good ideas here.
I have been meaning to come up with some kind of solution to the problem of "self-blocking" LP_DEAD bit setting within the kill_prior_tuple mechanism. It's hard to argue against that. > I'm out of time to do anything for this CF, so I've moved this back to later > CF. > > I'm planning to work on this more, but I won't try to fold in all of > your ideas above. Not cos they are bad ones, just there is enough room > for 2-4 related patches here. I'm a little concerned about relying on the indexUnchanged flag like this. It is currently just supposed to be a hint, but your proposal makes it truly critical. Currently the consequences are no worse than the risk that we'll maybe waste some cycles on the occasional useless bottom-up index deletion pass. With your patch it absolutely cannot be falsely set (though it should still be okay if it is falsely unset). Of course it should be correct (with or without this new optimization), but the difference still matters. And so I think that there ought to be a clear benefit to users from the new optimization, that justifies accepting the new risk. Some kind of benchmark showing an improvement in latency and/or throughput. Something like that. Doesn't have to be a huge improvement. -- Peter Geoghegan