drkp

_And_ it wasn't even originally designed to be used for concurrency control at all...

I have some experience with that specific question, although it was a few years ago...

Do you remember what conflict was causing things to fall over?

In general, the usual important parameters to tweak are:

- max_pred_locks_per_transaction may need to be increased; otherwise locks will switch to coarse granularity to save room in the lock table

- for tables that fit in memory, the planner may choose a sequential scan even when an index scan is available, which can be faster but creates more conflicts on a serializable workload. Increasing cpu_tuple_cost should avoid that (or even just enable_seqscan=off to force indexes whenever available)

Thanks! Glad you have been enjoying them.

You're correct that SI with a single writer will always be serializable.

(I was one of the authors of SSI in Postgres)