Skip site navigation (1) Skip section navigation (2)

Re: Reliable and fast money transaction design

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Ron Johnson" <ron(dot)l(dot)johnson(at)cox(dot)net>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Reliable and fast money transaction design
Date: 2007-08-29 21:22:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:

> Tom Lane wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>> Tom Lane wrote:
>>>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>>>> SERIALIZABLE is really slow :).
>>>> Say what?  If anything it's probably faster than READ COMMITTED, because
>>>> it doesn't take as many snapshots.  But the difference is likely down in
>>>> the noise anyway.
>>> Not in production it isn't.
>> Well, I can believe that specific applications might be slower overall
>> due to having to retry transactions that get serialization failures,
>> or perhaps because they take more locks to prevent such failures.
>> But it's not slower as far as the database engine is concerned.
> Well I can only speak to live production loads. I have never profiled
> the difference from that low of a level. I can definitely say that in a
> standard web app, under velocity, serializable is a huge performance killer.

Are you having to retry after serialization failures frequently?

There's no reason for an individual transaction to take longer in SERIALIZABLE
mode. In fact I believe SERIALIZABLE mode is actually measurably faster in
benchmarks but haven't run one in READ COMMITTED mode recently (for that

  Gregory Stark

In response to


pgsql-general by date

Next:From: Ken.ColsonDate: 2007-08-29 21:26:49
Subject: show connection limit?
Previous:From: BenDate: 2007-08-29 20:27:47
Subject: Re: autovacuum not running

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group