Re: Setting visibility map in VACUUM's second phase

On Friday, December 07, 2012 12:06 AM Robert Haas wrote:
> On Thu, Dec 6, 2012 at 1:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I think taking a second whack at setting the visibility bit is a fine
> > idea, but let's drop all the rest of this premature optimization.
>
> +1.
>
> If there's any optimization needed here, we should try to do it by
> remembering relevant details from the first vacuum pass in
> backend-private memory, rather than by changing the on-disk format.
>
> One other thought: I'm wondering if we shouldn't try to push the work
> of setting the all-visible bit into heap_page_prune(). That would
> allow HOT pruning to set the bit. For example, consider an
> all-visible page. A tuple is HOT-updated and the page becomes
> not-all-visible. Now the page is pruned, removing the old tuple and
> changing the line pointer to a redirect. Presto, page is all-visible
> again.

I think it can reduce some load of Vacuum as well, but the only thing is
it should not make
Page prune as heavy.
By the way, isn't this idea similar to patch at below link:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php

With Regards,
Amit Kapila.