Правило квадратного корня для задержек обязательств рухнет выше этого порога нагрузки

Stop tuning your group commit timer. Above a device-set load threshold, the parameter-free greedy-pipelined flush policy (flush the instant the device is free) matches any oracle-tuned timer within 0.1%. That's from a new paper that models group commit as a closed queueing network - the real world, not the textbook open-loop fantasy.

The textbook says you need an optimal timer: the EOQ square-root rule $T^\star=\sqrt{2F_0/\lambda}$ for Poisson arrivals, or a ski-rental 2-competitive wait-or-flush decision. That's open-loop theory. In actual OLTP, clients are closed-loop: they wait for their commit to complete before issuing the next transaction. The arrival rate is induced by the policy's own latency. Model that correctly, and the greedy-pipelined policy self-clocks to a fixed point. No tuning knob required.

The Device-Set Load Threshold That Makes Tuning Vacuous

The key insight is the relationship $T^\star \lambda^\star=2/F_0$. Above this device-set load threshold, the optimal timer collapses onto zero - the greedy policy. Below that threshold, the clean theory applies, but in practice most production databases run above $\lambda^\star$ on modern storage. The paper measures fsync distributions on two AWS storage classes: EBS gp3 and instance NVMe, spanning a 25x range in latency. Both confirm the effect: the threshold is easily exceeded under realistic loads.

PostgreSQL Confirms: commit_delay=0 is Competitive

They tested directly on PostgreSQL, the most common open-source database with a commit_delay parameter. Setting commit_delay=0 (the greedy flush) was competitive with any tuned value across their workloads. No need for adaptive policies, no square-root calculus, no ski-rental gymnastics. Just flush when the device is free. The paper's contribution is a characterization that explains why deployed practice already defaults to zero - and why your tuning efforts above a moderate load are wasted.

This characterization gives you a simple decision rule: compute your $\lambda^\star$ from your fsync latency, and if your commit rate exceeds it, stop tuning and go work on something that actually matters.

Source: Group Commit Self-Clocks: Why Tuning Is Unnecessary Above a Device-Set Load Threshold
Domain: arxiv.org