Andrew Sullivan <ajs@xxxxxxxxxxxxxxx> writes: > On Thu, Aug 30, 2007 at 03:32:40PM -0400, Tom Lane wrote: >> difference is that SERIALIZABLE takes one snapshot at transaction start >> and works with that for the whole transaction, whereas READ COMMITTED >> takes a new snap for each statement. > Oh, I get it. This explains then why in principle READ COMMITTED > oughta be faster in the absence of conflicts: additional snapshot > checks are not needed? To my mind it ought to be slower in principle: computing snapshots isn't free (though it's not tremendously expensive either, unless you have a huge number of active backends). The actual tuple visibility checks are going to be about the same speed either way, it's only a question of which snapshot you are using. Anyway, this is probably all down in the noise compared to the details of what is happening on the application level. If you end up having to retry a lot of serialization failures, or if you use stronger locking to avoid such failures (thereby losing concurrency), you'll more than swamp out any possible engine-level difference. I suspect that something of the sort is responsible for JD's experiences. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
