Re: Block B-Tree concept

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