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: 87ejhmavdz.fsf@oxford.xeocode.com (view raw or flat)
Thread:
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
reason).

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

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-2014 The PostgreSQL Global Development Group