On Thu, Apr 1, 2021 at 6:14 AM Robert Haas <robertmh...@gmail.com> wrote: > Without offering an opinion on this particular implementation choice, > +1 for the idea of trying to make the table-with-indexes and the > table-without-indexes cases work in ways that will feel similar to the > user. Tables without indexes are probably rare in practice, but if > some behaviors are implemented for one case and not the other, it will > probably be confusing. One thought here is that it might help to try > to write documentation for whatever behavior you choose. If it's hard > to document without weasel-words, maybe it's not the best approach.
I have found a way to do this that isn't too painful, a little like the VACUUM_FSM_EVERY_PAGES thing. I've also found a way to further simplify the table-without-indexes case: make it behave like a regular two-pass/has-indexes VACUUM with regard to visibility map stuff when the page doesn't need a call to lazy_vacuum_heap() (because there are no LP_DEAD items to set LP_UNUSED on the page following pruning). But when it does call lazy_vacuum_heap(), the call takes care of everything for lazy_scan_heap(), which just continues to the next page due to considering prunestate to have been "invalidated" by the call to lazy_vacuum_heap(). So there is absolutely minimal special case code for the table-without-indexes case now. BTW I removed all of the lazy_scan_heap() utility functions from the second patch in my working copy of the patch series. You were right about that -- they weren't useful. We should just have the pruning wrapper function I've called lazy_scan_prune(), not any of the others. We only need one local variable in the lazy_vacuum_heap() that isn't either the prune state set/returned by lazy_scan_prune(), or generic stuff like a Buffer variable. -- Peter Geoghegan
