> 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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers