Re: Reliable and fast money transaction design

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> 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