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

Re: Much Ado About COUNT(*)

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>,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-17 01:32:02
Message-ID: 20050117013202.GY67721@decibel.org (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-patches
On Sun, Jan 16, 2005 at 07:28:07PM -0600, Jim C. Nasby wrote:
> On Sun, Jan 16, 2005 at 08:01:36PM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <decibel(at)decibel(dot)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?

Er, nevermind, I thought about it and realized the issue.

What changes when a delete is done on a tuple? It seems that's the
key... if a tuple has been marked as possibly being expired/deleted,
don't allow it to go into known_good unless you can verify that the
transaction that marked it as potentially deleted was rolled back.
-- 
Jim C. Nasby, Database Consultant               decibel(at)decibel(dot)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?"

In response to

pgsql-announce by date

Next:From: Tom LaneDate: 2005-01-17 01:34:58
Subject: Re: Much Ado About COUNT(*)
Previous:From: Jim C. NasbyDate: 2005-01-17 01:28:07
Subject: Re: Much Ado About COUNT(*)

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-17 01:34:58
Subject: Re: Much Ado About COUNT(*)
Previous:From: Jim C. NasbyDate: 2005-01-17 01:28:07
Subject: Re: Much Ado About COUNT(*)

pgsql-patches by date

Next:From: Tom LaneDate: 2005-01-17 01:34:58
Subject: Re: Much Ado About COUNT(*)
Previous:From: Jim C. NasbyDate: 2005-01-17 01:28:07
Subject: Re: Much Ado About COUNT(*)

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