Re: A possible TODO item
От | Tom Lane |
---|---|
Тема | Re: A possible TODO item |
Дата | |
Msg-id | 4261.1167586341@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | A possible TODO item ("Gurjeet Singh" <singh.gurjeet@gmail.com>) |
Ответы |
Re: A possible TODO item
|
Список | pgsql-hackers |
"Gurjeet Singh" <singh.gurjeet@gmail.com> writes: > The comment above TOAST_INDEX_HACK in tuptoaster.h is: > /* > * This enables de-toasting of index entries. Needed until VACUUM is > * smart enough to rebuild indexes from scratch. > */ > #define TOAST_INDEX_HACK > Do we already have a TODO item to remove this hack? If not, I think there > should be, because it is waiting for some other progress to happen. Like what? If you want to argue that it's important to work on, you'd better make the case for that. At first glance you might think that turning it off would Just Work, because VACUUM should always remove index entries before removing heap rows, but unfortunately an index might have more copies of a key than just the one in the directly associated index entry. (btree, for example, might have copied the key into a page "high key" and/or boundary keys in upper tree levels. Those copies will persist long after the underlying row is gone.) And surely we are never going to make VACUUM force a complete REINDEX as the comment suggests. So any change in the situation is going to require considerable work as well as some good ideas we haven't thought of yet. Plus, it's unclear that values large enough to require out-of-line storage are reasonable candidates for indexing in the first place. So: what's the argument that is going to persuade everyone that this is really important? regards, tom lane
В списке pgsql-hackers по дате отправления: