ROOTRACE — The AI That Must Prove Its Fix.

Excessive per-call query fanout due to per-customer fetches

Mechanism:

customer_summary_slow issues a separate query for each of the 501 customers, resulting in 501 queries per call and heavy client-side loop overhead

What was actually run (direct):

query fanout eliminated via a single GROUP BY query (customer_summary_fast)

speed ratio 200.74× · 95% CI [176.17, 224.07] · Holm p 1.02e-5

Output identical to baseline: yes · ratio recomputed in your browser from the raw samples: matches

evaluator verdict: SUPPORTED

High JSON serialization and network overhead per query

Mechanism:

each of the 501 queries returns a small JSON response that must be serialized and transmitted, inflating total latency

What was actually run (proxy):

per-row Python object construction cost, with query count held fixed at the observed 501 queries per call

speed ratio 1.05× · 95% CI [0.90, 1.16] · Holm p 8.61e-1

Output identical to baseline: yes · ratio recomputed in your browser from the raw samples: matches

Predicted at least 2.0x; the measured interval is below that and includes no meaningful gain.

evaluator verdict: FALSIFIED

Missing index causing slow query execution on the database side

Mechanism:

the individual per-customer queries likely scan large portions of the underlying table repeatedly, leading to high execution time per query

What was actually run (direct):

per-query execution cost with an index on orders.customer_id, fanout unchanged

speed ratio 1.00× · 95% CI [0.86, 1.10] · Holm p 8.61e-1

Output identical to baseline: yes · ratio recomputed in your browser from the raw samples: matches

Predicted at least 2.0x; the measured interval is below that and includes no meaningful gain.

evaluator verdict: FALSIFIED

Thread pool saturation from launching many concurrent queries

Mechanism:

spawning 501 queries per call may saturate the application's thread pool or executor, causing context‑switch overhead and higher latency

What was actually run (precondition):

concurrent/thread-pooled query dispatch

Nothing was measured for this hypothesis.

Precondition check found no thread-pool or async primitives in the incident code, so the mechanism is absent. No experiment was run.

evaluator verdict: NOT_APPLICABLE

Point lookups on customer_id perform a full table scan.

Mechanism:

Add an index on orders(customer_id) so each lookup probes instead of scanning.

What was actually run (direct):

CREATE INDEX idx_orders_customer ON orders(customer_id)

speed ratio 4.09× · 95% CI [3.49, 4.83] · Holm p 6.78e-6

Output identical to baseline: yes · ratio recomputed in your browser from the raw samples: matches · one-off setup (index build): 564 ms, not in the timings

evaluator verdict: SUPPORTED

The orders table lacks an index on its primary-looking column.

Mechanism:

Add an index on orders(order_id). The lookup query does not filter on order_id.

What was actually run (decoy (plausible but wrong column)):

CREATE INDEX idx_orders_order ON orders(order_id)

speed ratio 0.91× · 95% CI [0.84, 1.15] · Holm p 6.19e-1

Output identical to baseline: yes · ratio recomputed in your browser from the raw samples: matches · one-off setup (index build): 351 ms, not in the timings

evaluator verdict: FALSIFIED