Re: Block B-Tree concept - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Block B-Tree concept
Date
Msg-id 200609270938.k8R9ccC05084@momjian.us
Whole thread Raw
In response to Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Block B-Tree concept  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> > Couldn't vacuum just eliminate tuples marked dead? Heck, don't we do
> > that anyway right now?
> 
> You mean _index_ tuples marked dead? Sure, no problem there.
> 
> > Granted, you'd want to periodically ensure that you scan the entire
> > index, but that shouldn't be horribly hard to set up.
> 
> Well, it seems to be.  A vacuum can't evaluate index expressions because 
> it's not in a real transaction.
> 
> The DBA could set up a cron job to do "SELECT * FROM foo WHERE bar > 0" 
> etc. with enable_seqscan=false? That would work, but we can't depend on 
> an additional administrative task like. And we might as well just 
> disable the optimization that's causing us problems.

Why can't the C code just do a full index scan that touches the heap,
sets those expired bits, and then do a vacuum?  My point is that the
bits can be set outside the normal vacuum process, so you don't have to
be doing heap lookups from the index inside vacuum.

Assuming the heap is mostly in index order, the full index scan
shouldn't take much longer than a heap scan, and if the heap doesn't
match index order, a block index shouldn't be used anyway.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Markus Schaber
Date:
Subject: Ignore that mail (was: jar in repository)
Next
From: Heikki Linnakangas
Date:
Subject: Re: Block B-Tree concept