Skip site navigation (1) Skip section navigation (2)

Re: Much Ado About COUNT(*)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
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 20:11:37
Message-ID: 19315.1105906297@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-patches
Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> 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?

There's no race condition, since resetting the hint only forces other
transactions to go back to the original data (the tuple header) to
decide what to do.  AFAICS the above is safe; I'm just pretty dubious
about the cost.

> AFAICS we'd need two new bits: "visible to all" and "maybe dead".

No, you've got this wrong.  The three possible states are "known visible
to all", "known dead to all", and "uncertain".  If you see "uncertain"
this means you have to go to the heap and compare the XIDs in the tuple
header to your snapshot to decide if you can see the row or not.  The
index states are not the same as the "known committed good" or
"known committed dead" hint bits in the tuple header --- those can be
set as soon as the inserting/deleting transaction's outcome is known,
but we can't move the index entry into the "visible to all" or "dead to
all" states until that outcome is beyond the GlobalXmin event horizon.

			regards, tom lane

In response to

Responses

pgsql-announce by date

Next:From: Tom LaneDate: 2005-01-16 20:22:11
Subject: Re: Much Ado About COUNT(*)
Previous:From: Manfred KoizarDate: 2005-01-16 19:49:45
Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-16 20:22:11
Subject: Re: Much Ado About COUNT(*)
Previous:From: Tom LaneDate: 2005-01-16 20:01:41
Subject: Re: WAL logging of heap_mark4update

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-01-16 20:13:26
Subject: Re: Increased error verbosity when querying row-returning
Previous:From: Brendan JurdDate: 2005-01-16 19:58:41
Subject: Re: Increased error verbosity when querying row-returning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group