3 ms·

Yeah, Postgres's implementation of SERIALIZABLE is not efficient (at least compared to the default). I'm not really sure how any implementation can be particul

• anarazel 10y ago
  > 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.
• href 10y ago
  In my personal use I found the overhead to be negligible. But then I've never used it for a project that really had to scale. For simple CRUD applications SERIALIZABLE is great, because you basically don't have to worry about concurrent updates anymore. Well worth the price imho.