In CockroachDB 1.x, pushing a serializable transaction's timestamp was tantamount to aborting it, so we were very conservative about when we did it. The RefreshSpans mechanism introduced in 2.0 makes pushing a transaction's timestamp much cheaper, so we should consider doing it more often.

Specifically, there are two opportunities where it might make sense to push the timestamp:

• PushTxn: We currently only push the timestamp if the pushee is snapshot, but extending this to serializable transactions as well would unblock the pusher at the expense of requiring a refresh in the pushee
• Command queue: Reads in the command queue block writes at lower timestamps, but not higher timestamps. Pushing a write's timestamp may allow it to proceed without blocking.

As a motivating example for pushing timestamps from the command queue, consider a workload consisting mainly of point writes with perioidic full-table reads (from #25405 (comment)). Currently, the read acts as a barrier and forces writes to stall: the read can't proceed while any writes are in flight, and concurrent writes are blocked until the read completes. AS OF SYSTEM TIME queries are recommended as a workaround, but this raises the question of what timestamp should be used. If reads in the command queue didn't block writes but instead pushed their timestamps (as is already the case for past reads in the timestamp cache), the point writes would be able to continue uninterrupted while the read is in progress.

Jira issue: CRDB-5705