From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block B-Tree concept |
Date: | 2006-09-26 12:51:10 |
Message-ID: | 23964.1159275070@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> VACUUM?
>>
> There's a few options that I've thought of this far:
> 1. Whenever a tuple is found dead on page X, vacuum of the index will
> have to go to that page again to see if there's any matching tuples left.
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?
> 2. Have a reference counter on index tuple that's increased on insert
> and decreased by vacuum.
The "increase on insert" part I understand, the "decrease by vacuum"
part seems to have the same problem as #1. How do you tell which index
entries should be changed?
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-26 13:00:33 | Re: heap_markpos and heap_restrpos |
Previous Message | Simon Riggs | 2006-09-26 12:39:24 | Re: Please to technical check of upcoming release |