ср, 25 нояб. 2020 г. в 19:41, Peter Geoghegan <p...@bowt.ie>:
> We have promising tuples for bottom-up deletion. Why not have > "promising heap blocks" for traditional LP_DEAD index tuple deletion? > Or if you prefer, we can consider index tuples that *don't* have their > LP_DEAD bits set already but happen to point to the *same heap block* > as other tuples that *do* have their LP_DEAD bits set promising. (The > tuples with their LP_DEAD bits set are not just promising -- they're > already a sure thing.) > In the _bt_delete_or_dedup_one_page() we start with the simple loop over items on the page and if there're any LP_DEAD tuples, we're kicking off _bt_delitems_delete(). So if I understood you right, you plan to make this loop (or a similar one somewhere around) to track TIDs of the LP_DEAD tuples and then (perhaps on a second loop over the page) compare all other currently-not-LP_DEAD tuples and mark those pages, that have at least 2 TIDs pointing at (one LP_DEAD and other not) as a promising one. Later, should we require to kick deduplication, we'll go visit promising pages first. Is my understanding correct? > I am missing a general perspective here. > > > > Is it true, that despite the long (vacuum preventing) transaction we can > re-use space, > > as after the DELETE statements commits, IndexScans are setting LP_DEAD > hints after > > they check the state of the corresponding heap tuple? > > The enhancement to traditional LP_DEAD deletion that I just described > does not affect the current restrictions on setting LP_DEAD bits in > the presence of a long-running transaction, or anything like that. > That seems like an unrelated project. The value of this enhancement is > purely its ability to delete *extra* index tuples that could have had > their LP_DEAD bits set already (it was possible in principle), but > didn't. And only when they are nearby to index tuples that really do > have their LP_DEAD bits set. > I wasn't considering improvements here, that was a general question about how this works (trying to clear up gaps in my understanding). What I meant to ask — will LP_DEAD be set by IndexScan in the presence of the long transaction? -- Victor Yegorov
