User @erichocean on gitter was interested in using AOST in a way that avoids having to pick a timestamp manually. Concretely, the AOST read would try to read the latest data, but skips open transactions, with the requirements that AOST never a) block and b) interfere with writes.

In CockroachDB, commit timestamps are chosen when the transaction starts. To get these semantics, AOST queries would have to a) lower their timestamps and restart every time they run into an intent, which is inefficient. The alternative b) is running at a fixed offset in the past and running at high priority, but this forces the writes to refresh (their outcome doesn't change, so the refresh should just work).

In Spanner, by comparison, commit timestamps are chosen only when the writes are written out, and read locks are taken before that. This means that AOST queries will block writes to the same keys, so they technically also violate the constraint above. They don't force the writes to restart, but neither does CockroachDB (a refresh is cheaper; it's just another round of reads). So arguably option b) is closest here, but it requires manual choice of a timestamp.

It's not clear that one is better than the other, but users intuitively expect the commit timestamp to be chosen at commit time.

A related idea by @erichocean was to let each node keep track of the lowest timestamp for their open transactions, and gossip this. When running AOST, use the lowest known gossiped timestamp at high priority.

This wasn't particularly high priority.