Re: [HACKERS] HOT WIP Patch - version 2
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] HOT WIP Patch - version 2 |
Дата | |
Msg-id | 200702201443.l1KEhjE20912@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] HOT WIP Patch - version 2 ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
Список | pgsql-patches |
Pavan Deolasee wrote: > On 2/20/07, Bruce Momjian <bruce@momjian.us> wrote: > > > > Pavan Deolasee wrote: > > > When following a HOT-update chain from the index fetch, if we notice > > that > > > the root tuple is dead and it is HOT-updated, we try to prune the chain > > to > > > the smallest possible length. To do that, the share lock is upgraded to > > an > > > exclusive lock and the tuple chain is followed till we find a > > > live/recently-dead > > > tuple. At that point, the root t_ctid is made point to that tuple. In > > order > > > > I assume you meant recently-dead here, rather than live/recently-dead, > > because we aren't going to change live ctids, right? > > > No, I meant live or recently-dead (in fact, anything other than > HEAPTUPLE_DEAD > or HEAPTUPLE_DEAD_CHAIN). > > We are not changing the tids here, but only pruning the HOT-update chain. > After pruning, the root->t_ctid points to the oldest tuple that might be > visible to any backend. The live tuples are still identified by their > original tid and index reachable from the root tuple. I am confused. Where is the root->t_ctid stored? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: