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
Re: Block B-Tree concept Re: Block B-Tree concept |
Список | 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 по дате отправления: