M5: TPC-C with statements #5

This milestone decides gate G5: TPC-C with plain statements at 3x the NOPM per core of PostgreSQL 19, at the same durability. It adds the HammerDB driver in its statement form, the two warehouse counts, the consistency check after each run and the write amplification number.

Why

M5 completes the transaction model, and TPC-C is the suite that shows whether it holds under contention. With plain statements each New-Order makes 5 + 2n round trips, so the floor of the round trip limits the ratio, and the target is 3x and not 10x. The published PostgreSQL reference of about 9,000 NOPM per core is a reference only. The gate uses PostgreSQL 19 measured by us on oltp with the same driver.

A TPC-C number on a device with slow sync measures the device. On gpc the fdatasync p50 of 2,247 µs caps any engine at about 385,000 NOPM with 32 terminals. So the gate runs on oltp, and the sync bound is printed next to each durable result.

The work

• Drive rupg and PostgreSQL 19 with HammerDB TPROC-C in its client side statement form, and record the HammerDB version (spec/20 §20.8)
• Run the two warehouse counts that M0 fixed: one that fits in the memory budget and one 4 times larger (spec/20 §20.8)
• Run a ramp of 5 minutes and a measured interval of 20 minutes, at the virtual user count of the PostgreSQL 19 peak and at the count of the rupg peak (spec/20 §20.8)
• Run the server in a cpuset of 16 cores and report NOPM per core as NOPM divided by 16 (spec/20 §20.2)
• Publish the synchronous_commit = on row, which decides the gate, and the synchronous_commit = off row for both systems (spec/20 §20.8, spec/02 §2.7.4)
• Print the sync bound 0.45 x 60 x T / s next to each durable result, with the measured fdatasync p50 (spec/20 §20.8)
• Report NOPM, the p50, p95 and p99 of each transaction type, usage_usec, memory.peak and the device write bytes (spec/20 §20.8)
• Report the write amplification against the budget of a ratio below 3 on TPC-C (spec/19 §19.10.2)
• Check that the TPC-C memory is not higher than PostgreSQL's at the same buffer pool size (spec/19 §19.12.3)
• Run the consistency conditions 1 to 4 of clause 3.3.2 on both systems after each run, and do not publish a run that fails one (spec/21 §21.4.6)
• Add 100 TPC-C new-order transactions to the instruction count set (spec/21 §21.14)

Exit criterion

1. G5: on oltp with synchronous_commit = on for both systems, rupg reaches at least 3x the NOPM per core of PostgreSQL 19 with plain statements.
2. Every published run passed the consistency conditions of clause 3.3.2.
3. The report gives both warehouse counts, both durability rows, the sync bound and the write amplification against its budget of 3.
4. The G5 number has the five parts of spec/02 §2.2, and the PostgreSQL 19 baseline was measured within 30 days.

Engine milestone

• M5: Transactions in full rupg#6

Depends on

• M4: ClickBench below ClickHouse #4

Spec

• spec/02 §2.7.2 TPC-C
• spec/02 §2.7.4 Durability is the same on both sides
• spec/03 §3.12.2 The commit floor on our machine
• spec/19 §19.10.2 The bytes in motion
• spec/20 §20.8 TPC-C
• spec/21 §21.4.6 Benchmark consistency
• spec/23 §23.8 M5: transactions in full