From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Much Ado About COUNT(*) |
Date: | 2005-01-16 19:49:45 |
Message-ID: | j9hlu0t1h3mnruj2uhlge0fn0qmsha1utr@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-announce pgsql-hackers pgsql-patches |
On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>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
>set again.
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
conditions?
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
visibility.
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.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-01-16 20:11:37 | Re: Much Ado About COUNT(*) |
Previous Message | Stuart Bishop | 2005-01-16 06:30:11 | Re: PostgreSQL 8.0.0 Release Candidate 4 |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2005-01-16 19:51:06 | Re: WAL logging of heap_mark4update |
Previous Message | lsunley | 2005-01-16 17:13:05 | Re: OS/2 port regression tests |
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2005-01-16 19:58:41 | Re: Increased error verbosity when querying row-returning |
Previous Message | Tom Lane | 2005-01-16 19:43:18 | Re: Increased error verbosity when querying row-returning |