Re: Thoughts on "killed tuples" index hint bits support on standby - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: Thoughts on "killed tuples" index hint bits support on standby
Date
Msg-id CANtu0ohTwjAVMzv7V5a=mZH-KjATdEyFssVbmD-Zk62iEE1_yw@mail.gmail.com
Whole thread Raw
In response to Re: Thoughts on "killed tuples" index hint bits support on standby  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Thoughts on "killed tuples" index hint bits support on standby
List pgsql-hackers
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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Should we make Bitmapsets a kind of Node?
Next
From: John Naylor
Date:
Subject: Re: Perform COPY FROM encoding conversions in larger chunks