[Bug] Identical exact query-time aggregates are not shared across queries #922

Example

Two identical exact queries should cost the same as one: the second reads the first one's result. Today the planner builds a second copy of the exact aggregate.

Workload base.json (one SQL query, exact p99 over 5 minutes every 30 s):

{"query_workload":{"language":{"sql":"datafusion_sql"},"query_batch":null,"repeating_queries":[{"query":"SELECT percentile_cont(0.99) WITHIN GROUP (ORDER BY value) AS v FROM metrics WHERE ts > now() - INTERVAL '5' MINUTE","demand":{"fixed_interval":30000},"requirements":{"accuracy":{"max_error":0.0,"failure_probability":0.0,"accuracy_scope":"whole_result"},"max_latency_ms":null},"predictability":{"predictable":{"known_at":null}}}]},"data_workload":{"arrival":{"ingesting":{"rows_per_second":1000.0}},"sources":{"metrics":{"series_count":10000,"metric_type":null,"values_non_negative":true,"sample_interval":10000,"stream_norms":null,"max_distinct_per_evaluation":null,"distinct_values_per_label":{"city":10,"host":100}}}}}

Workload related.json (the same query twice):

{"query_workload":{"language":{"sql":"datafusion_sql"},"query_batch":null,"repeating_queries":[{"query":"SELECT percentile_cont(0.99) WITHIN GROUP (ORDER BY value) AS v FROM metrics WHERE ts > now() - INTERVAL '5' MINUTE","demand":{"fixed_interval":30000},"requirements":{"accuracy":{"max_error":0.0,"failure_probability":0.0,"accuracy_scope":"whole_result"},"max_latency_ms":null},"predictability":{"predictable":{"known_at":null}}},{"query":"SELECT percentile_cont(0.99) WITHIN GROUP (ORDER BY value) AS v FROM metrics WHERE ts > now() - INTERVAL '5' MINUTE","demand":{"fixed_interval":30000},"requirements":{"accuracy":{"max_error":0.0,"failure_probability":0.0,"accuracy_scope":"whole_result"},"max_latency_ms":null},"predictability":{"predictable":{"known_at":null}}}]},"data_workload":{"arrival":{"ingesting":{"rows_per_second":1000.0}},"sources":{"metrics":{"series_count":10000,"metric_type":null,"values_non_negative":true,"sample_interval":10000,"stream_norms":null,"max_distinct_per_evaluation":null,"distinct_values_per_label":{"city":10,"host":100}}}}}

cargo run -p asap-devtools --bin stage_pipeline -- --workload base.json --table '{"columns":[{"name":"ts","nullable":false,"type":"timestamp"},{"name":"city","nullable":false,"type":"utf8"},{"name":"host","nullable":false,"type":"utf8"},{"name":"value","nullable":false,"type":"float64"}],"name":"metrics","time_index":0}' --enforce-accuracy-guarantees --out base.out.json
cargo run -p asap-devtools --bin stage_pipeline -- --workload related.json --table '{"columns":[{"name":"ts","nullable":false,"type":"timestamp"},{"name":"city","nullable":false,"type":"utf8"},{"name":"host","nullable":false,"type":"utf8"},{"name":"value","nullable":false,"type":"float64"}],"name":"metrics","time_index":0}' --enforce-accuracy-guarantees --out related.out.json
# same two commands with --exhaustive: identical selected plans and costs

Expected: related.json costs about 0.078023 (the witness), not 0.098187.

Re-verified on current main (stage_pipeline built at 65655b6); the numbers above are from that run.

Current behavior

The duplicate adds 0.020164 per second, about 26% of the base cost, instead of nothing.

Same class, other cases:

• A second exact percentile rank over the same input (percentile_cont(0.99) plus percentile_cont(0.5), relation e-other-quantile-rank, seed 11 case 7): 0.098187 selected vs 0.088187 witness.
• A duplicated PromQL topk (3, sum_over_time(m_gauge[2m])) (relation f-exact-duplicate, seed 11 case 52): 0.000149 selected vs 0.000137 witness.

Expected behavior and invariant

For the workload with the added query, the selected cost should not exceed the base cost plus the cost of deriving the added query from the base plan, within a small tolerance. The cheaper plan (the witness) is priced by Stage 2 and Stage 3 with the same models as the search and passes Stage 3's checks, but the search never selects it.

Minimal reproduction

The two stage_pipeline commands above. planner_fuzz found it (seeds and relation names are under Status and related work). Running with --exhaustive selects the same plan and the same cost, so no candidate rule generates the cheaper plan; it is a missing candidate, not a search miss.

Why it happens

Not diagnosed. The exact query-time aggregate of the second query is planned as its own node instead of being identified with the first query's node, so its cost is counted twice. Exact query-time aggregates appear to be outside the sharing that Pass 2 does for stored summaries.

Regression test

Plan base.json and related.json and assert cost(related) - cost(base) <= derive_cost + tolerance. Today it fails with the numbers above.

Status and related work

Related: #903 (its P3-m1 case shows the same unshared identical exact aggregate) and #580 (Stage 2 shared query-time work). Found by planner_fuzz seed 11, relations f-exact-duplicate and e-other-quantile-rank.