Hi Peter,
Sorry for bringing up so old thread since I have some troubles to
understand what is going on here. I'd start with something I can
understand then raise my question I have right now.
>
> The difference here is that we're simply making an intelligent guess
> -- there have been no index scans, but we're going to do a kind of
> special index scan at the last minute to see if we can avoid a page
> split.
"Index scans" would cause the "simple index deletion" work and this
"bottom-to-up" deletion works for the cases where the index scan doesn't
happen.
Index page split is expensive. Before the index page split, if we can
remove the tuples which are invisible to all the clients, then some room
may be saved, then the saved room may avoid the index page split
totally. This is the general goal of this patch.
IIUC, to detect some tuples, we have to go to heap page for the MVCC
check, this is not free. So a important part of this patch is to
intelligent guess which leaf page needs the "bottom-to-up
deletion". This is the place I start to confuse. By checking the
commits message / README, looks two metrics are used here. One is
"logically unchanged index" hint, from
"Each bottom-up deletion pass is triggered lazily in response
to a flood of versions on an nbtree leaf page. This usually involves a
"logically unchanged index" hint (these are produced by the executor
mechanism added by commit 9dc718bd)."
The other one is latestRemovedXid. from
"The LP_DEAD deletion process (which is now
called "simple deletion" to clearly distinguish it from bottom-up
deletion) won't usually need to visit any extra table blocks to check
these extra tuples. We have to visit the same table blocks anyway to
generate a latestRemovedXid value (at least in the common case where the
index deletion operation's WAL record needs such a value)."
So my questions are: (a) How does the "logically unchanged index" hint
can be helpful for this purpose? (b). What does the latestRemovedXid
means, and which variable in code is used for this purpose. I searched
"latestRemovedXid" but nothing is found. (c) What is the relationship
between a and b. I mean if we *have to visit" the same table blocks (in
the case of index-split?), then the IO-cost is paid anyway, do we still
need the "logically unchanged index hint"?
At last, appreciated for your effort on making this part much better!
--
Best Regards
Andy Fan
