Re: vacuum, performance, and MVCC
От | Bruce Momjian |
---|---|
Тема | Re: vacuum, performance, and MVCC |
Дата | |
Msg-id | 200606271616.k5RGGRi26939@momjian.us обсуждение исходный текст |
Ответ на | Re: vacuum, performance, and MVCC (Hannu Krosing <hannu@skype.net>) |
Ответы |
Re: vacuum, performance, and MVCC
|
Список | pgsql-hackers |
Hannu Krosing wrote: > ?hel kenal p?eval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing: > > ?hel kenal p?eval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian: > > > Jim C. Nasby wrote: > > > > On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote: > > > > > > > > > > It is certainly possible to do what you are suggesting, that is have two > > > > > index entries point to same chain head, and have the index access > > > > > routines figure out if the index qualifications still hold, but that > > > > > seems like a lot of overhead. > > > > I think Jim meant not 2 pointing to the same head, but 2 pointing into > > the same chain. Say we have table with (id serial, ts timestamp) where > > ts changes at each update and id does not. > > > > So after 3 updates on one page we have one CITC/ITPC head with pointers > > from both indexes and two follow-up tuples with pointers from only ts > > index. > > > > The problem with this setup is, that we can't reuse any of those > > follow-up tuples without index cleanup. > > But we still have to think about similar cases (index entries pointing > inside CITC chains), unless we plan to disallow adding indexes to > tables. CREATE INDEX has to undo any chains where the new indexed columns change in the chain, and add index entries to remove the chain. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: