Re: Thoughts on "killed tuples" index hint bits support on standby

Hello, Peter.

> Yeah, it would help a lot. But those bits are precious. So it makes
> sense to think about what to do with both of them in index AMs at the
> same time. Otherwise we risk missing some important opportunity.

Hm. I was trying to "expand the scope" as you said and got an idea... Why
we even should do any conflict resolution for hint bits? Or share precious
LP bits?

The only way standby could get an "invalid" hint bit - is an FPI from the
primary. We could just use the current *btree_mask* infrastructure and
clear all "probably invalid" bits from primary in case of standby while
applying FPI (in `XLogReadBufferForRedoExtended`)!
For binary compatibility, we could use one of `btpo_flags` bits to mark the
page as "primary bits masked". The same way would work for hash\gist too.

No conflicts, only LP_DEAD bit is used by standby, `btpo_flags` has many
free bits for now, easy to implement, page content of primary\standby
already differs in this bits...
Looks like an easy and effective solution for me.

What do you think?

>> Also, btw, do you know any reason to keep minRecoveryPoint at a low
value?
> Not offhand.

If so, looks like it is not a bad idea to move minRecoveryPoint forward
from time to time (for more aggressive standby index hint bits). For each
`xl_running_xacts` (about each 15s), for example.

> BTW, what happens when the page splits on the primary, btw? Does your
> patch "move over" the LP_DEAD bits to each half of the split?

That part is not changed in any way.

Thanks,
Michail.