Re: Much Ado About COUNT(*)

decibel <decibel@decibel.org>

From: "Jim C. Nasby" <decibel@decibel.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Manfred Koizar <mkoi-pg@aon.at>, Bruce Momjian <pgman@candle.pha.pa.us>, "Jonah H. Harris" <jharris@tvi.edu>, pgsql-hackers@postgresql.org
Date: 2005-01-17T01:28:07Z
Lists: pgsql-hackers
On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > Wouldn't the original proposal that had a state machine handle this?
> > IIRC the original idea was:
> 
> > new tuple -> known good -> possibly dead -> known dead
> 
> Only if you disallow the transition from possibly dead back to known
> good, which strikes me as a rather large disadvantage.  Failed UPDATEs
> aren't so uncommon that it's okay to have one permanently disable the
> optimization.

Actually, I guess I wasn't understanding the problem to begin with.
You'd never go from new tuple to known good while the transaction that
created the tuple was in-flight, right? If that's the case, I'm not sure
where there's a race condition. You can't delete a tuple that hasn't
been committed, right?
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"