Parent: #281
Goal
Add a fast path for dashboard metrics and summary queries that should not require repeatedly scanning trace-span Parquet files.
Dashboards tend to issue repeated aggregate queries over recent windows. They should use precomputed or narrower summary data where correctness allows it.
Scope
- Identify dashboard metrics and summary requests that can be served from summary tables or bounded aggregate paths.
- Keep raw trace-span scans available for requests that need span-level detail.
- Add freshness behavior that makes summary results safe under ongoing ingestion.
- Track fast-path hit rate, fallback rate, latency, and object-store request count.
High-level design
The goal is not to move the whole analytical workload to Postgres. The goal is to avoid using the most expensive raw-span path for queries whose result shape is already summary-oriented.
This issue should clarify which queries are eligible for the fast path and which must stay on the raw DataFusion path.
Acceptance criteria
- Eligible dashboard queries use the metrics/summary fast path.
- Ineligible queries fall back to the existing raw-span DataFusion path.
- Freshness behavior is explicit and tested.
- Metrics show fast-path hit rate and fallback reasons.
- Benchmarks show dashboard latency and object-store request-count impact.
Parent: #281
Goal
Add a fast path for dashboard metrics and summary queries that should not require repeatedly scanning trace-span Parquet files.
Dashboards tend to issue repeated aggregate queries over recent windows. They should use precomputed or narrower summary data where correctness allows it.
Scope
High-level design
The goal is not to move the whole analytical workload to Postgres. The goal is to avoid using the most expensive raw-span path for queries whose result shape is already summary-oriented.
This issue should clarify which queries are eligible for the fast path and which must stay on the raw DataFusion path.
Acceptance criteria