Re: Much Ado About COUNT(*)
От | Jim C. Nasby |
---|---|
Тема | Re: Much Ado About COUNT(*) |
Дата | |
Msg-id | 20050117012807.GX67721@decibel.org обсуждение исходный текст |
Ответ на | Re: Much Ado About COUNT(*) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Much Ado About COUNT(*)
Re: Much Ado About COUNT(*) |
Список | 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?"
В списке pgsql-hackers по дате отправления: