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

Re: Much Ado About COUNT(*)

From: Jochem van Dieten <jochemd(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Much Ado About COUNT(*)
Date: 2005-01-17 01:24:57
Message-ID: f96a9b830501161724c16ab9e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-announcepgsql-hackerspgsql-patches
On Sun, 16 Jan 2005 20:01:36 -0500, Tom Lane wrote:
> "Jim C. Nasby" 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.

But how about allowing the transition from "possibly dead" to "new
tuple"? What if a failed update restores the tuple to the "new tuple"
state, and only after that it can be promoted to "known good" state?

Jochem

In response to

pgsql-announce by date

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

pgsql-hackers by date

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

pgsql-patches by date

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

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