On Fri, Nov 20, 2020 at 4:21 PM Peter Geoghegan <p...@bowt.ie> wrote: > Actually, now I think that BRIN shouldn't be special to vacuumlazy.c > in any way. It doesn't make sense as part of this future world in > which index vacuuming can be skipped for individual indexes (which is > what I talked to Sawada-san about a little earlier in this thread). > Why should it be useful to exploit the "no-real-TIDs" property of BRIN > in this future world? It can only solve a problem that the main > enhancement is itself expected to solve without any special help from > BRIN (just the generic am callback that asks the same generic question > about index vacuuming urgency). > > The only reason we press ahead with a second scan (the > LP_DEAD-to-LP_UNUSED thing) in this ideal world is a heap/table > problem. The bloat eventually gets out of hand *in the table*. We have > now conceptually decoupled the problems experienced in the table/heap > from the problems for each index (mostly), so this actually makes > sense. The theory behind AV scheduling becomes much closer to reality > -- by changing the reality! (The need to "prune the table to VACUUM > any one index" notwithstanding -- that's still necessary, of course, > but we still basically decouple table bloat from index bloat at the > conceptual level.) > > Does that make sense?
I *think* so. For me the point is that the index never has a right to insist on being vacuumed, but it can offer an opinion on how helpful it would be. -- Robert Haas EDB: http://www.enterprisedb.com
