Skip site navigation (1) Skip section navigation (2)

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

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
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 06:31:29
Message-ID: CABOikdME0UyH9ATKN9y9dcWBMwo7DZdhD-_nTe5eCK1Kyt=vBw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

I'd also suggested doing something similar for cases when a table is
created and written in the same transaction. But that's more invasive.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-10 06:43:28
Subject: Re: dynamic SQL - possible performance regression in 9.2
Previous:From: Amit KapilaDate: 2013-01-10 06:15:47
Subject: Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group