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

Re: Dead Space Map for vacuum

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgresql(dot)org,"Jochem van Dieten" <jochemd(at)gmail(dot)com>
Subject: Re: Dead Space Map for vacuum
Date: 2007-01-04 04:42:50
Message-ID: 20070104131654.63B1.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
"Jochem van Dieten" <jochemd(at)gmail(dot)com> wrote:

> On 12/28/06, ITAGAKI Takahiro wrote:
> >
> > | [TODO item] Allow data to be pulled directly from indexes
> > | Another idea is to maintain a bitmap of heap pages where all rows are
> > | visible to all backends, and allow index lookups to reference that bitmap
> > | to avoid heap lookups
> >
> > It is not done yet, but we can use DSM for this purpose. If the corresponding
> > bit in DSM is '0', all tuples in the page are frozen and visible to all
> > backends. We don't have to look up frozen pages only for visibiliby checking.
> 
> Does that really work in the absence of a retail index vacuum method?
> What if the heap is already vacuumed, frozen and the bit for that page
> in the DSM is set to '0', but the index still contains entries that
> haven't been removed by a vacuum yet?

No, if the DSM bit is 0, there are no frozen nor dead tuples in the page
and no dead index entries linking to tuples in it. In other words, we can
reset DSM to 0 only in such condition.

BTW, if we want to achieve the index-only scan, we might have to do more
aggressive VACUUM FREEZE. There were many comments that we should avoid
vacuuming pages that contain only unfrozen tuples or a few dead tuples.
I think it it true for efficient VACUUM, but the index-only scan does not
work for the unfrozen pages. Which should we give priority?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2007-01-04 05:04:37
Subject: Re: proposal - new SPI cursor function
Previous:From: uwcssaDate: 2007-01-04 03:51:58
Subject: costing for arbitrary path

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