Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Pavan Deolasee'" <pavan(dot)deolasee(at)gmail(dot)com>, "'Bruce Momjian'" <bruce(at)momjian(dot)us>
Cc: "'Josh Berkus'" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL
Date: 2013-01-10 09:18:05
Message-ID: 006a01cdef13$66aaa950$33fffbf0$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, January 10, 2013 12:01 PM Pavan Deolasee wrote:
> On Thu, Jan 10, 2013 at 11:45 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
> wrote:
> > On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>
> >>
> >> Surely VACUUM FULL should rebuild the visibility map, and make
> tuples
> >> in
> >> the new relation all-visible, no?
> >
> > I think it cannot made all visible.
> > How about if any transaction in SSI mode is started before Vacuum
> Full, should it see all tuples.
> >
>
> We can definitely do better than what we are doing today and that
> should fix many use cases and rebuild the VM for large part of the
> table if not all. More precisely, in cluster.c we can see what does
> HeapTupleSatisfiesVacuum() returns for every tuple in a page. If there
> are only DEAD or LIVE tuples in a page, we can set the VM bit. We may
> need similar additional checks for LIVE tuples like we have in vacuum
> code path. But its certainly doable.

>> Do we document this behavior or add a TODO item?

> Both?

IMO, we should do both.

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-01-10 09:25:17 Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Previous Message Simon Riggs 2013-01-10 09:10:33 Re: Enabling Checksums