Re: Overhead cost of Serializable Snapshot Isolation - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Overhead cost of Serializable Snapshot Isolation
Date
Msg-id 20111011202149.GO3007@tinybird.home
Whole thread Raw
In response to Re: Overhead cost of Serializable Snapshot Isolation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Overhead cost of Serializable Snapshot Isolation  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Overhead cost of Serializable Snapshot Isolation  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Robert Haas:
> Serializable mode is much slower on this test, though.  On
> REL9_1_STABLE, it's about 8% slower with a single client.  At 8
> clients, the difference rises to 43%, and at 32 clients, it's 51%
> slower.

Bummer. Thanks for putting some numbers out there; glad I was able
to jump start a deeper look at this. Based on this thread so far,
I am probably going to avoid serializable in this particular case,
and stick to repeatable read. Once things are in place, perhaps I'll
be able to try switching to serializable and get some measurements,
but I wanted to see if the impact was minor enough to safely start
with serializable. Seems not. :) Keep in mind this is not even a
formal proposal yet for our client, so any benchmarks from me may
be quite a while.

Kevin Grittner:

> Did these transactions write anything?  If not, were they declared
> to be READ ONLY?  If they were, in fact, only reading, it would be
> interesting to see what the performance looks like if the
> recommendation to use the READ ONLY attribute is followed.

Yes, I'll definitely look into that, but the great majority of the
things done in this case are read/write.

Simon Riggs:
> Most apps use mixed mode serializable/repeatable read and therefore
> can't be changed by simple parameter. Rewriting the application isn't
> a sensible solution.
>
> I think it's clear that SSI should have had and still needs an "off
> switch" for cases that cause performance problems.

Eh? It has an off switch: repeatable read.


Thanks for all replying to this thread, it's been very helpful.


--
Greg Sabino Mullane greg@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Overhead cost of Serializable Snapshot Isolation
Next
From: Kääriäinen Anssi
Date:
Subject: Re: Index only scan paving the way for "auto" clustered tables?