On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs <simon.riggs@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