Re: Set visibility map bit after HOT prune

On Sunday, December 16, 2012 11:14 PM Tom Lane wrote:
> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > On Sun, Dec 16, 2012 at 3:10 PM, Simon Riggs <simon(at)2ndquadrant(dot)com>
> wrote:
> >> As explained above, I disagree that it looks like a good idea, and
> >> you've shown no evidence it would be or is true.
>
> > Lets separate out these two issues. What you are suggesting as a
> > follow up to Tom's idea, I've no objection to that and that might be
> > worthwhile optimisation to try out. But this patch itself does not
> > attempt to deal with that and its a separate work item and will
> > require invasive changes and tests.
>

> Another thing that would need to be considered, if we do want to
> restrict when pruning happens, is whether it is worth introducing some
> other path altogether for setting the all-visible bit. Or perhaps we
> should modify autovacuum's rules so that it will fire on relations for
> which there might be lots of unmarked all-visible pages.

Can something similar be also used for putting deleted index pages into FSM.

The reason is that currently deleted index pages are recorded in FSM in the
next Vacuum cycle.
So if after bulk index update (always increasing order), even if the auto
vacuum is done once, it still does not put
deleted index pages into FSM.
Now let's assume there are no operations which can lead to auto-vacuum on
same table, next cycle of bulk update will allocate
new index pages.
I had observed this in one of the tests that if bulk index update happens
such that new value is always increasing, then index bloat happens. As per
initial analysis, it seems one of the reasons is what I described above.
If required, I can create a self-containing test which can show that
bulk-index update can lead to index bloat.

With Regards,
Amit Kapila.