Re: Block B-Tree concept

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Block B-Tree concept
Дата
Msg-id 23964.1159275070@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: Block B-Tree concept  (Csaba Nagy <nagy@ecircle-ag.com>)
Re: Block B-Tree concept  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Block B-Tree concept  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
Heikki Linnakangas <heikki@enterprisedb.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Please to technical check of upcoming release
Следующее
От: Tom Lane
Дата:
Сообщение: Re: heap_markpos and heap_restrpos