On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>A would-be deleter of a tuple would have to go and clear the "known
>good" bits on all the tuple's index entries before it could commit.
>This would bring the tuple back into the "uncertain status" condition
>where backends would have to visit the heap to find out what's up.
>Eventually the state would become certain again (either dead to
>everyone or live to everyone) and one or the other hint bit could be
Last time we discussed this, didn't we come to the conclusion, that
resetting status bits is not a good idea because of possible race
In a previous post you wrote:
| I think we still have one free bit in index tuple headers...
AFAICS we'd need two new bits: "visible to all" and "maybe dead".
Writing the three status bits in the order "visible to all", "maybe
dead", "known dead", a normal index tuple lifecycle would be
000 -> 100 -> 110 -> 111
In states 000 and 110 the heap tuple has to be read to determine
The transitions 000 -> 100 and 110 -> 111 happen as side effects of
index scans. 100 -> 110 has to be done by the deleting transaction.
This is the operation where the additional run time cost lies.
One weakness of this approach is that once the index tuple state is
110 but the deleting transaction is aborted there is no easy way to
reset the "maybe deleted" bit. So we'd have to consult the heap for
the rest of the tuple's lifetime.
In response to
pgsql-announce by date
|Next:||From: Tom Lane||Date: 2005-01-16 20:11:37|
|Subject: Re: Much Ado About COUNT(*) |
|Previous:||From: Stuart Bishop||Date: 2005-01-16 06:30:11|
|Subject: Re: PostgreSQL 8.0.0 Release Candidate 4|
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2005-01-16 19:51:06|
|Subject: Re: WAL logging of heap_mark4update|
|Previous:||From: lsunley||Date: 2005-01-16 17:13:05|
|Subject: Re: OS/2 port regression tests|
pgsql-patches by date
|Next:||From: Brendan Jurd||Date: 2005-01-16 19:58:41|
|Subject: Re: Increased error verbosity when querying row-returning|
|Previous:||From: Tom Lane||Date: 2005-01-16 19:43:18|
|Subject: Re: Increased error verbosity when querying row-returning |