> Yeah, Postgres's implementation of SERIALIZABLE is not efficient (at least compared to the default). Sure, you pay some price. But if that overhead actually

> Yeah, Postgres's implementation of SERIALIZABLE is not efficient (at least compared to the default). Sure, you pay some price. But if that overhead actually proves to be a problem for you, we'd like to hear about it. There's definitely some room for optimizations, but so far fewer people hit those than some people (i.e. me) anticipated. > I'm not really sure how any implementation can be particularly efficient. It seems that either an implementation would have to maintain a huge number of specific row locks or you have to start locking whole tables. You don't need full row locks, and you can summarize up "ranges" of locks if necessary for space reasons. I.e. go from row level to page level, to full table level. That will still be correct, just cause more rollbacks.