# v0.102.0: Output-sensitive delta performance

> **Status:** Planned
> **Scope:** Large
> **User promise:** *"Small relevant changes avoid unnecessary scans, and expensive refreshes explain their cost."*
> **Blocked by:** [v0.101.0](v0.101.0.md)
> **Source:** [September 2026 assessment](../plans/pg-trickle-assessment-and-pre-1.0-roadmap.md)

## Theme

Reduce work outside the changed inputs, relevant state, and changed outputs.
Measure those costs separately so unavoidable fanout is not mistaken for an
engine regression.

## Work

- Record bounded per-operator rows and bytes examined, affected keys, groups,
  and partitions, output changes, state work, WAL, temporary bytes, and index
  writes.
- Improve delta statistics and cost decisions for joins and aggregates.
- Admit key restriction, predicate pushdown, shared-delta, or bounded
  join-order rewrites one rule at a time.
- Include planning, execution, apply, lock wait, and commit time in refresh
  evidence.
- Publish the generated SQL and PostgreSQL plan used for each measured path.
- Keep optional window and TopK candidates disabled unless their full lifecycle
  and end-to-end benchmark win.

## Exit criteria

- [ ] Each enabled optimization has exact-result, schema, and snapshot parity
      tests plus retained benchmark evidence.
- [ ] Target workloads meet a preset material-win threshold, and neighboring
      workloads stay within their regression budgets.
- [ ] Plan and cache invalidation covers relevant schema, identity, function,
      collation, and statistics changes.
- [ ] High-fanout workloads report output amplification instead of claiming
      universal work proportional only to the input delta.
- [ ] Missing statistics select a safe current plan.

## Scope control

Do not build an independent physical join optimizer or require a new Arrow or
SIMD runtime. Remove a losing optimization or leave it experimental.