SerializableToDo

From PostgreSQL wiki
Jump to: navigation, search

A list of smaller ideas for improvements to SERIALIZABLE:

  • Does TABLESAMPLE really need to predicate-lock whole relations? Discussion
  • Does index-only-scan really need to predicate-lock whole pages? Discussion Discussion
  • Can exclude constraint violations be made to check for SSI failures, like we did for unique constraint violations? Discussion
  • Ugh. It doesn't even work correctly for multi-btree tables. Bug report

Bigger ideas to investigate:

  • SSI didn't turn out to scale very well past a few cores, due to contention on a couple of LWLocks. Redesign locking protocol, find a better way to clean up finished transactions that isn't so contended? This "garbage collection" is currently serialized and performs terribly.
  • Can we use hardware transactional memory to implement SSI efficiently? Early stage experimental patch
  • Can we allow SERIALIZABLE READ ONLY DEFERRABLE transactions on streaming replica nodes? Early stage experimental patch Thomas's blog on the topic
  • Can we allow scan order to be magically changed (conceptually like SKIP LOCKED, but you wouldn't actually say that) to allow queue-like access patterns to minimise conflicts, to fix the famous worst case for optimistic concurrency control schemes like SSI? Thomas's blog on the topic
  • Can we export SSI conflict graphs over postgres_fdw? Suppose we have a 2PC-based multi-server transactions as proposed, then there could be a system to merge all of the conflict graphs from remote nodes into the lead server's transaction set. Transactions could be rejected 'locally' in cases where individual nodes can prove they are not serializable, and global dangerous cycles could be detected after merging the graphs. This requires a way to label SERIALIZABLEXACTs (probably with xid on lead server). Then we could have federated SERIALIZABLE transactions (but only when everyone goes through the same head node).