In Global setting, when write is done at 9 but completed at 12, the transaction doing write is being held by commit for longer. Can that be done async to make transaction faster?
The transaction only waits for the write at 12 to complete if it has no other work. Unfortunately, it’s not possible to allow the transaction to commit before time 12 (and do the wait asynchronously), as if we did that, a subsequent transaction initiated by the same application which reads before time 12 would not be able to see the row, thus breaking our ACID guarantees.
@@cockroachdb Would it actually violate ACID? I think the strongest "I" in ACID is "serializable", and for that I think you'd just have to not allowing any other mutating transactions to start before t=11, right? "serializable" would even allow totally stale reads, so it seems like returning early shouldn't be an issue. I think it's the "linearizable" property that would be violated...but that said...it's basically still "linearizable" to all processes other than the writer. The writer essentially just got a sneak peak into the future. This seems like it could have utility in a batch update scenario where you're sure you're not going to need to read your own write immediately (and therefore won't stumble into the non-linearizable behavior). It could potentially reduce the "memory-seconds" needed for the batch update job pretty significantly, maybe it's worth consider having this as an option?
