# v0.108.0: Measured core improvements

> **Status:** Planned, conditional on measurements
> **Scope:** Small
> **User promise:** "Core changes fix proven defects or reduce measured database cost while preserving incremental results."
> **Blocked by:** [v0.107.0](v0.107.0.md)
> **Source:** [Post-v0.105.2 assessment](../pg-trickle-v0.105.2-assessment.md), sections 6.2 through 6.5

## Outcome

Select at most two internal changes from reproduced defects or the qualified
workload measurements. If no candidate meets the criteria, retain the profiling
record and defer the release. There is no code-deletion target or required
rewrite.

## Work

- Profile the v0.106.0 workload set with representative stream-table counts,
  retained history, skew, affected groups, join fanout, wide rows, and output
  consumers. Record maintenance work relative to affected results and state,
  not only input change count.
- Measure `batch_update_cost_model_summary()` as retained history and stream
  count grow. Separate scheduler bookkeeping, cleanup contention, and refresh
  execution. Freeze the tested sizes and housekeeping latency, CPU, and I/O
  budgets before comparing changes.
- If history scans exceed the declared budget, use a bounded recent window
  or incremental summary within the existing cost-model design. Preserve
  documented statistics and reset semantics. If that is not possible, defer
  the change pending an explicit compatibility decision.
- If a reproduced SQL-generation defect justifies a change, carry the minimum
  structural facts already available in the operator tree. Avoid rediscovering
  aliases, outer predicates, identity, or current, pre-change, and unchanged
  relation semantics from rendered SQL. Keep semantic fixes separate from
  unrelated cleanup and give each one a minimized regression.
- Alternatively, fix a measured affected-key scan, materialization, repeated
  catalog lookup, or cleanup bottleneck at its shared implementation point.
  Choose the smallest change that addresses the measured cause.
- Compare baseline and candidate packages under identical workload and
  durability conditions. Retain raw results, query plans, exact bag and schema
  parity, effective strategy, and applicable recovery and output-delta checks.
  Include cancellation and spill cases for changes to resource-sensitive work.

## Exit criteria

- [ ] Each selected change names a reproduced defect or measured cost, its
      baseline, and a success threshold chosen before implementation.
- [ ] Optimizations meet their improvement threshold outside the declared
      measurement noise in repeated package runs. Correctness fixes demonstrate
      failure before the change and success after it without a performance
      regression. Both remain within the v0.106.0 foreground-write, freshness,
      resource, and microbenchmark budgets.
- [ ] Housekeeping measurements cover aged history and the supported stream
      counts. Any summary change preserves statistics and reset behavior.
- [ ] Exact-result, strategy, recovery, and relevant Graph V1 and Delta V1
      checks pass for the changed paths on the shipping candidate.
- [ ] Differential maintenance remains preferred where supported. Any fallback
      remains visible, justified, and correctness-preserving. An unintended
      whole-query `FULL` path cannot count as an optimization.
- [ ] Changes without demonstrated benefit are dropped. The profiling record
      states whether a release is justified.

## Existing implementation points

Start with the [refresh orchestrator](../src/refresh/orchestrator.rs),
[pipeline](../src/refresh/pipeline.rs),
[DVM operators](../src/dvm/operators/), and the workload and evidence tools
qualified in [v0.106.0](v0.106.0.md).

## Scope control

No general SQL framework, snapshot abstraction, new scheduling algorithm,
speculative cache, or new GUC without a demonstrated need. Preserve source
durability, frozen public contracts, capture defaults, and controller authority.
This work adds no SQL families, integration behavior, or PostgreSQL major
targets. It neither delays earlier corrective releases nor starts the deferred
72-hour soak, longevity environment, release candidates, or v1.0 release.