Re: Overhead cost of Serializable Snapshot Isolation

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(at)endpoint(dot)com
End Point Corporation
PGP Key: 0x14964AC8