Re: Reliable and fast money transaction design

"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