Paul Hemberger

That seems much simpler (I think I tried something similar but put the abort_on_panic in the wrong place), we can always revive this change if we do need the specificity...

@danhhz got rid of `blob-batch-exists`, and added an optional `reuse-write-handle` param to write commands -- I tried reintroducing short-lived writers across the board, but it makes writing/testing/reasoning about the state...

> It's breaking production to not have limits set at all. Do we run the Kube nodes with any kube/system resource allocations? We might be able to mark off some...

@danhhz mind double checking the heartbeat placement in `append_batch`?

Amazing! Thank you Matt 🙇

Downgraded the interesting-ness of this PR a bit. I couldn't find a way to fast-path-insert-or-read in a single RTT to CRDB, and I removed the pipeline read for now --...

Debating whether I want to dedicate time to write a test for the consolidating... it's tricky because it's in an async task. I think it could be done through something...

@aljoscha this seems to be tied to the current `advance_local_inputs` behavior, which writes an empty batch + calls `downgrade_since` once a second on each table. The shorter we can make...

I've also been wondering - do tables need to have `downgrade_since` called immediately after each `advance_local_inputs`, or could those calls be staggered from one another? e.g. calling `maybe_downgrade_since` would automatically...

This would be very useful! I see https://github.com/weaveworks-experiments/kspan/pull/36 is up and looks ready to go, any hesitations with merging it in?