| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
| 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:01:36 |
| Message-ID: | 20927.1105923696@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-announce pgsql-hackers pgsql-patches |
"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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jochem van Dieten | 2005-01-17 01:24:57 | Re: Much Ado About COUNT(*) |
| Previous Message | Jim C. Nasby | 2005-01-17 00:53:01 | Re: Much Ado About COUNT(*) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jochem van Dieten | 2005-01-17 01:24:57 | Re: Much Ado About COUNT(*) |
| Previous Message | Jim C. Nasby | 2005-01-17 00:53:01 | Re: Much Ado About COUNT(*) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jochem van Dieten | 2005-01-17 01:24:57 | Re: Much Ado About COUNT(*) |
| Previous Message | Jim C. Nasby | 2005-01-17 00:53:01 | Re: Much Ado About COUNT(*) |