On 9/18/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > On 9/18/07, Tom Lane <[EMAIL PROTECTED]> wrote: > >> In a system with > >> HOT running well, the reasons to vacuum a table will be: > >> > >> 1. Remove dead index entries. > >> 2. Remove LP_DEAD line pointers. > >> 3. Truncate off no-longer-used end pages. > >> 4. Transfer knowledge about free space into FSM. > >> > >> Pruning cannot accomplish #1, #2, or #3, and without significant > changes > >> in the FSM infrastructure it has no hope about #4 either. > > > I guess we already have mechanism to remove dead index entries > > outside vacuum. > > Not a trustworthy one --- unless you have a solid proposal for making it > work with bitmap indexscans, it would be foolish to design autovacuum > behavior on the assumption that dead index entries aren't a problem. > >
Hmm.. I think we need to drop this for now because I am sure any such proposal would need a lot more discussion. May be something we can pick up for 8.4 So we go back to tracking dead tuples. I would still be inclined towards tracking non-HOT dead tuples or subtract the count of pruned HOT tuples because we don't want to trigger autovacuum too often, rather let pruning clean as much dead space as possible. What it means also that the tuple storage reclaimed by pruning a non-HOT dead tuples does not impact the autovacuum behavior, positively or negatively. And ISTM that this does not address 4 ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
