Re: [HACKERS] HOT WIP Patch - version 2 - Mailing list pgsql-patches

From Pavan Deolasee
Subject Re: [HACKERS] HOT WIP Patch - version 2
Date
Msg-id 2e78013d0702200638y7e03090che0a46beb10783a2d@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] HOT WIP Patch - version 2  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] HOT WIP Patch - version 2  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches

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.

Thanks,
Pavan

--

EnterpriseDB     http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: correct format for date, time, timestamp for XML functionality
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] HOT WIP Patch - version 2