Re: Thoughts on "killed tuples" index hint bits support on standby
От | Peter Geoghegan |
---|---|
Тема | Re: Thoughts on "killed tuples" index hint bits support on standby |
Дата | |
Msg-id | CAH2-Wz=MKS08oBbc2mPyS_MT+2SVwK_XJFvstco=o-K_OW+qQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Thoughts on "killed tuples" index hint bits support on standby (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Thoughts on "killed tuples" index hint bits support on standby
|
Список | pgsql-hackers |
On Wed, Jan 27, 2021 at 5:24 PM Peter Geoghegan <pg@bowt.ie> wrote: > The issue here is that it would also be nice to use a "recently dead" > bit on the primary, but if you do that then maybe you're back to the > original problem. OTOH, I also think that we could repurpose the > LP_NORMAL bit in index AMs, so we could potentially have 3 different > definitions of dead-ness without great difficulty! To be clear, what I mean is that you currently have two bits in line pointers. In an nbtree leaf page we only currently use one -- the LP_DEAD bit. But bringing the second bit into it allows us to have a representation for two additional states (not just one), since of course the meaning of the second bit can be interpreted using the LP_DEAD bit. You could for example having encodings for each of the following distinct per-LP states, while still preserving on-disk compatibility: "Not known to be dead in any sense" (0), "Unambiguously dead to all" (what we now simply call LP_DEAD), "recently dead on standby" (currently-spare bit is set), and "recently dead on primary" (both 'lp_flags' bits set). Applying FPIs on the standby would have to be careful to preserve a standby-only bit. I'm probably not thinking of every subtlety, but "putting all of the pieces of the puzzle together for further consideration" is likely to be a useful exercise. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: