Re: Reliable and fast money transaction design - Mailing list pgsql-general

From Gregory Stark
Subject Re: Reliable and fast money transaction design
Date
Msg-id 87ejhmavdz.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Reliable and fast money transaction design  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Reliable and fast money transaction design  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Reliable and fast money transaction design  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-general
"Joshua D. Drake" <jd@commandprompt.com> writes:

> Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> Tom Lane wrote:
>>>> "Joshua D. Drake" <jd@commandprompt.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

pgsql-general by date:

Previous
From: Ben
Date:
Subject: Re: autovacuum not running
Next
From: "Joshua D. Drake"
Date:
Subject: PostgreSQL Conference Fall 2007