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

From Heikki Linnakangas
Subject Re: Block B-Tree concept
Date
Msg-id 45195136.8000309@enterprisedb.com
Whole thread Raw
In response to Re: Block B-Tree concept  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Block B-Tree concept  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Block B-Tree concept  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Anything that involves having VACUUM re-evaluate index expressions is a
> nonstarter ... or have you already forgotten the optimizations we put
> into 8.2 that assume, eg, no sub-transactions within a VACUUM?

Umm, I'm afraid I have. Could you give me a clue?

>> 3. Do nothing. Let index scans mark the index tuple as dead when it's
>> convenient. There's no correctness problem with just leaving dead index
>> tuples there, because you have to check the index quals on each heap
>> tuple anyway when you scan.
>
> And we're back to routine REINDEX I guess :-(. This doesn't seem like a
> satisfactory answer.

In general, it isn't.

Though there are interesting use cases where it would be fine. For 
example, if you remove old data by dropping a partition, there's never 
really need to vacuum. Or if all of the data is accessed during normal 
operation, the index scans set the LP_DELETE flags and no additional 
vacuum is really needed.

Also, now that we have concurrent CREATE INDEX, we could implement 
concurrent REINDEX as well, I believe.

-- 
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [ADMIN] pg_hba.conf: 'trust' vs. 'md5' Issues
Next
From: Tom Lane
Date:
Subject: Re: horo(r)logy test fail on solaris (again and solved)