Re: Open issues for HOT patch

On 9/18/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > On 9/18/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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