On Tue, Jun 19, 2018 at 8:05 AM, Peter Geoghegan <p...@bowt.ie> wrote: > On Mon, Jun 18, 2018 at 2:54 PM, Peter Geoghegan <p...@bowt.ie> wrote: >> On Sun, Jun 17, 2018 at 9:39 PM, Andrey V. Lepikhov >> <a.lepik...@postgrespro.ru> wrote: >>> Patch '0001-retail-indextuple-deletion' introduce new function >>> amtargetdelete() in access method interface. Patch >>> '0002-quick-vacuum-strategy' implements this function for an alternative >>> strategy of lazy index vacuum, called 'Quick Vacuum'.
Great! >> >> My compiler shows the following warnings: > > Some real feedback: > > What we probably want to end up with here is new lazyvacuum.c code > that does processing for one heap page (and associated indexes) that > is really just a "partial" lazy vacuum. Though it won't do things like > advance relfrozenxid, it will do pruning for the heap page, index > tuple killing, and finally heap tuple killing. It will do all of these > things reliably, just like traditional lazy vacuum. This will be what > your background worker eventually uses. I think that we do the partial lazy vacuum using visibility map even now. That does heap pruning, index tuple killing but doesn't advance relfrozenxid. Since this patch adds an ability to delete small amount of index tuples quickly, what I'd like to do with this patch is to invoke autovacuum more frequently, and do the target index deletion or the index bulk-deletion depending on amount of garbage and index size etc. That is, it might be better if lazy vacuum scans heap in ordinary way and then plans and decides a method of index deletion based on costs similar to what query planning does. Regards, -- Masahiko Sawada
