Group Commit Self-Clocks: Why Tuning Is Unnecessary Above a Device-Set Load Threshold

Abstract: Group commit amortizes the fixed cost of a durable log flush across many committing transactions; the release rule - a timer, a batch size, or an adaptive policy - is a classic tuning knob. The textbook theory is open-loop: for Poisson arrivals the optimal timer is the EOQ square-root rule, and the wait-or-flush decision is ski-rental 2-competitive. We ask when that tuning is worth its machinery, and show that in closed-loop OLTP it usually is not. Real commit arrivals are closed-loop: a client issues its next transaction only after its last commits, so the arrival rate is induced by the policy's own latency. Modeling this as a closed queueing network, the parameter-free greedy-pipelined policy (flush the instant the device is free) self-clocks to a computable fixed point and is within about 0.1% of the best oracle-tuned timer at every load. The square-root rule prescribes waiting $T<sup>\star=\sqrt{2F_0/λ}$, but $T<sup>\star&lt;F_0$ exactly when $λ&gt;λ<sup>\star=2/F_0$; above this device-set load threshold the timer collapses onto greedy and tuning is vacuous. The clean theory only bites below $λ<sup>\star$ and in the open-loop world, where a parameter-free ski policy still beats a fixed tuned timer under rate shifts. We instantiate $λ<sup>\star$ with measured fsync distributions on two AWS storage classes (EBS gp3 versus instance NVMe, a $25\times$ range), and confirm on PostgreSQL that commit_delay=0 is competitive with any tuned value. The contribution is a characterization that explains deployed practice; we add no new logger.

• The paper shows that a parameter-free greedy-pipelined policy self-clocks in closed-loop OLTP and stays within a median 0.1% of the best oracle-tuned timer across tested loads.
• The analysis proves that timer tuning becomes redundant above the threshold λc = 2/F0, where the prescribed wait is shorter than one flush and the system naturally behaves like greedy flushing.
• Experiments across AWS storage and PostgreSQL find λc values of about 2,200 commits/s for EBS gp3 and 55,000 commits/s for instance NVMe, while adaptive policies retain value mainly under open-loop bursty workloads.

Overview

This paper addresses a question upstream of a long line of group-commit tuning work: when is tuning the commit release rule worth its machinery at all? Group commit amortizes the fixed cost of a durable log flush ($F_0$, plus per-record $\delta$) across a batch of committing transactions, and every major engine exposes the release rule as a knob — PostgreSQL's commit_delay/commit_siblings, MySQL's binlog group commit. The classical analysis is open-loop: with exogenous Poisson arrivals at rate $\lambda$, the optimal timer follows the EOQ square-root rule $T^\star=\sqrt{2F_0/\lambda}$, and the wait-or-flush decision maps to ski-rental / dynamic TCP acknowledgment, which is 2-competitive deterministic (2606.18187).

The authors' central claim is that in closed-loop OLTP — where a bounded client pool means arrivals are induced by the policy's own latency — this tuning apparatus is largely unnecessary. A parameter-free greedy-pipelined policy (flush the instant the device is free) self-clocks to a computable fixed point and lands within roughly 0.1% of an oracle-tuned timer at every load. Above a device-set load threshold $\lambda_c = 2/F_0$, the square-root prescription collapses onto greedy and tuning becomes vacuous. The contribution is explicitly a characterization that explains deployed practice ("set commit_delay ≈ 0"), not a new logger; the underlying flush-pipelining mechanism is Aether's (2606.18187).

Closed-loop model and the load threshold

The model treats $N$ clients each thinking for $Z$ then blocking until its commit's flush completes, so $\lambda$ is endogenous: latency throttles the very arrivals it batches. The greedy-pipelined policy, analyzed as a closed queueing network via Little's law with the device back-to-back, yields the fixed point

$$K^\star = \frac{N\,F(K^\star)}{Z+\rho\,F(K^\star)}, \qquad X \to 1/\delta,$$

so throughput saturates at the write-bandwidth bound and batch size is computable without any tunable parameter.

The threshold result is the analytical core. The open-loop optimum prescribes waiting $T^\star = \sqrt{2F_0/\lambda}$, but $\delta$0 exactly when $\delta$1. Above this rate, the prescribed wait is shorter than a single flush duration, so the timer fires while the device is still busy and the batch flushes at device-free time regardless of $\delta$2 — the timer degenerates to greedy. Tuning can therefore only matter below $\delta$3 or in the genuinely open-loop world. This cleanly explains why practitioners find no reliable signal when sweeping commit_delay under realistic load.

Experimental results

The evaluation is pre-registered, with code, seeds, and the pre-registration public; notably, two pre-registered hypotheses were not supported as stated and were reframed by the data into the threshold result, which the authors disclose rather than hide.

Self-clocking fixed point. Greedy's simulated batch size and throughput match the closed-network prediction across $\delta$4, with batch error around 10% and throughput error around 7%; the device saturates as predicted.

Parameter-free optimality. Across all closed-loop loads, greedy is within a median 0.1% of the best oracle-tuned timer. Feeding the measured closed-loop $\delta$5 into the open-loop square-root rule yields exactly greedy's overhead (ratio 1.000) for all $\delta$6, diverging only below the threshold — a direct confirmation of the theory.

Where policy still matters. In the open-loop abstraction with rate shifts, a fixed timer tuned for the low rate suffers under bursts, while a parameter-free ski-rental policy adapts: ski reaches 1.34× the offline optimum versus the fixed timer's 1.44×. The gap is modest but real, and it locates the regime where competitive theory actually bites.

Real devices and PostgreSQL. Measured fsync distributions on two AWS storage classes instantiate $\delta$7 concretely:

Storage class	$\delta$8	p99	Implied $\delta$9
EBS gp3	0.90 ms	2.5 ms	≈ 2,200/s
Instance NVMe	0.036 ms	—	≈ 55,000/s

The 25× spread quantifies the "is group commit needed on fast storage?" question: on EBS gp3 essentially any non-trivial OLTP load exceeds $\lambda$0 so group commit matters, whereas on instance NVMe it barely matters until extreme load. Plugging measured distributions into the simulator, greedy is within 1.3% (EBS) and 0.1% (NVMe) of best-tuned. A PostgreSQL commit_delay sweep on pgbench with WAL on EBS shows commit_delay=0 within ~10% of the best tuned value at 32 clients (~6.6k tps, above $\lambda$1) with no reliable or monotonic signal; at 2 clients (below $\lambda$2) the benefit grows to ~17%, exactly the direction the threshold predicts. The practical upshot matches deployed folklore: leave commit_delay near zero and let the log self-clock.

Related positioning

Group commit originates with DeWitt et al. and Gawlick and Kinkade; Deb and Serfozo give the open-loop bulk-service optimum under known statistics; ski-rental and dynamic acknowledgment supply the rent-or-buy competitive framework used for the open-loop regime. Cloud log services such as Aurora replace $\lambda$3 with a network-tail distribution, shifting $\lambda$4 but not the structure of the argument. The framing builds on the observation that commit I/O dominates OLTP cost, which is what makes the regime question consequential.

Limitations

The authors are explicit about scope. The closed-loop competitive bound is conjectured, not proven; optimality is reported empirically. pgbench has non-commit bottlenecks and spot/EBS latency is variable, making the PostgreSQL arm noisy — the ~10% and ~17% figures carry that uncertainty. Two pre-registered hypotheses failed as stated. The mechanism enabling self-clocking is Aether's flush pipelining, so the paper's novelty rests entirely on the closed-loop analysis and threshold characterization. Open questions include a proof of the closed-loop competitive ratio and whether the threshold structure survives heterogeneous flush costs or replicated quorum acknowledgments beyond the network-tail substitution noted for Aurora.

Conclusion

The paper shows that the textbook open-loop theory of group-commit tuning misdescribes the regime real OLTP systems occupy. Under closed-loop arrivals, the parameter-free greedy policy self-clocks to a computable fixed point, matches oracle-tuned timers to within ~0.1% median overhead, and the square-root rule's prescription is provably vacuous above the device-set threshold $\lambda$5 — instantiated at ~2,200/s on EBS gp3 versus ~55,000/s on instance NVMe. Adaptive policy retains value only in open-loop settings with rate shifts, where ski-rental achieves 1.34× offline optimum against a tuned timer's 1.44×. The result is a debunking with explanatory force: it accounts for the widespread deployed practice of leaving commit delay at zero, and it delineates precisely the narrow conditions under which tuning machinery would be justified.