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

Re: Setting visibility map in VACUUM's second phase

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Setting visibility map in VACUUM's second phase
Date: 2012-12-06 18:35:58
Message-ID: CA+TgmoZHWN1+N_CGD3hx=DJPHkd69c8x2r2EiQ5=c8yxNrc8wA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Also, it seems to me that heap_page_prune() is already figuring out
most of the stuff we need to know in order to decide whether to set
PD_ALL_VISIBLE.  The logic looks quite different from what is
happening in the vacuum code, because the vacuum code iterates over
all of the line pointers while the pruning code is walking HOT chains.
 But it seems to me that a page can't be all-visible unless there are
no dead line pointers and no HOT chains of length != 1, and
heap_prune_chain() does manage to call HeapTupleSatisfiesVacuum() for
every tuple, so the raw information seems like it is available without
any additional CLOG lookups.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-12-06 18:36:47
Subject: Re: why can't plpgsql return a row-expression?
Previous:From: Jan WieckDate: 2012-12-06 18:34:08
Subject: Re: autovacuum truncate exclusive lock round two

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