[michae2]

Author here. We've spent the past year adding read committed isolation to CockroachDB.

There were many interesting design decisions, such as:

- whether to use multiple snapshots or a single snapshot per statement

- how to handle read uncertainty intervals

- how to incorporate SELECT FOR UPDATE locking into Raft

- how to handle SELECT FOR UPDATE subqueries

- how to prevent lost update anomalies between two UPDATEs

Some of the gory details are in the public RFC: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

This blog post just discusses the last point, but please AMA.

[sbstp]

Why is Cockroach adding READ COMMITTED? Is using a lower level of isolation better for performance or just reduces the amount of serialization errors and retries that need to be done?

[kogir]

READ COMMITTED is great for applications that need a coherent snapshot of the database but not necessarily the absolutely most recent data, which in my experience is actually most apps.

It allows readers to see valid data (relationships are correct), while not blocking writers. It can be the difference between constant deadlocks and super-high throughput without lock contention.

[michae2]

The main motivation is reduce serialization errors, for applications that can handle the weaker isolation level. Especially for applications that were previously running fine under RC on another database.

[nextaccountic]

Can this improvement also be implemented in Postgresql, removing the need for EvalPlanQual?

Maybe as an option with a new syntax (UPDATE .. WHERE .. RETRYING) or something like this.