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
