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

Re: Much Ado About COUNT(*)

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 (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-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


In response to

Responses

pgsql-announce by date

Next:From: Tom LaneDate: 2005-01-16 20:11:37
Subject: Re: Much Ado About COUNT(*)
Previous:From: Stuart BishopDate: 2005-01-16 06:30:11
Subject: Re: PostgreSQL 8.0.0 Release Candidate 4

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2005-01-16 19:51:06
Subject: Re: WAL logging of heap_mark4update
Previous:From: lsunleyDate: 2005-01-16 17:13:05
Subject: Re: OS/2 port regression tests

pgsql-patches by date

Next:From: Brendan JurdDate: 2005-01-16 19:58:41
Subject: Re: Increased error verbosity when querying row-returning
Previous:From: Tom LaneDate: 2005-01-16 19:43:18
Subject: Re: Increased error verbosity when querying row-returning

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