On Thu, Jul 01, 2021 at 09:22:38AM -0700, Peter Geoghegan wrote: > 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. >
Hi Simon, This has been stalled since July, and based on Peter's comment i feel we should mark this as RwF. Which i'm doing now. Please feel free to resubmit for Next Commitfest. -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL
