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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-announce pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-01-17 01:28:07 | Re: Much Ado About COUNT(*) |
Previous Message | Tom Lane | 2005-01-17 01:01:36 | Re: Much Ado About COUNT(*) |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-01-17 01:28:07 | Re: Much Ado About COUNT(*) |
Previous Message | Tom Lane | 2005-01-17 01:01:36 | Re: Much Ado About COUNT(*) |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-01-17 01:28:07 | Re: Much Ado About COUNT(*) |
Previous Message | Tom Lane | 2005-01-17 01:01:36 | Re: Much Ado About COUNT(*) |