Re: Using indexUnchanged with nbtree

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(dot)riggs(at)enterprisedb(dot)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