> Vlad Arkhipov wrote:
> 29.04.2011 21:18, Kevin Grittner wrote:
>> Vlad Arkhipov wrote:
>>> But even if it would work it would not help me anyways. Because
>>> my constraint is much more complex and depends on other tables, I
>>> cannot express it in terms of exclusion constraints.
>>
>> Are you aware of the changes to the SERIALIZABLE transaction
>> isolation level in the upcoming 9.1 release?
>>
>> http://wiki.postgresql.org/wiki/Serializable
>> http://wiki.postgresql.org/wiki/SSI
>>
>> If you can wait for that, it might be just what you're looking
>> for.
> I would not like to make the whole transaction serializable because
> of performance and concurrency reasons.
I'm curious -- what do you expect the performance and concurrency
impact to be? You do realize that unlike SELECT FOR UPDATE,
SERIALIZABLE in PostgreSQL 9.1 will not cause any blocking beyond
what is there in READ COMMITTED, right?
This is not like SERIALIZABLE in any other database. It is the first
production implementation of an innovative technique first published
in 2008. The paper in which it was introduced won a best paper award
from ACM SIGMOD. An ACM committee independently confirmed benchmarks
showing that performance was much better than blocking-based
SERIALIZABLE techniques, and very close to snapshot isolation for
many workloads.
Now, it might turn out that there's some reason it's not a good fit
for you, but don't assume that based on anything you know about any
*other* database's SERIALIZABLE isolation level; this is completely
different.
-Kevin