# v0.31.0 — Performance & Scheduler Intelligence

> **Full technical details:** [v0.31.0.md-full.md](v0.31.0.md-full.md)

**Status: ✅ Released** | **Scope: Medium**

> A smarter, faster scheduler with no changes to the SQL API — improvements
> that are invisible at the query level but measurable at scale.

---

## What is this?

v0.31.0 makes pg_trickle's internal scheduler significantly smarter and
faster. The SQL interface is unchanged — these are under-the-hood
improvements that show up as lower latency and higher throughput, especially
for deployments running hundreds or thousands of stream tables.

---

## Adaptive batching

Today the scheduler checks each stream table independently for new changes.
If five stream tables all watch the same source table, that source table is
scanned five times per refresh cycle. Adaptive batching coalesces those
scans: one scan per source table per tick, with the results distributed to
all downstream stream tables. Expected throughput improvement: 10–30% for
deployments with many stream tables sharing sources.

---

## Plan-aware refresh strategy

When refreshing a stream table, pg_trickle currently uses a fixed
`merge_strategy` setting that must be tuned manually. Plan-aware routing
automatically inspects the PostgreSQL query plan after each differential
refresh and switches strategy for the next cycle when the plan data suggests
a different approach would be faster. This eliminates a common manual
tuning step.

---

## Faster IVM trigger functions

PostgreSQL 18 introduced a way to reference in-flight row data (transition
tables) directly by name inside a trigger function, without first copying
that data into a temporary table. pg_trickle currently uses temporary tables,
which adds overhead on every data change. This release switches to the new
direct-reference approach, reducing the cost of the change-capture hot path.

---

## Better observability for lock contention

A new Prometheus counter tracks how often pg_trickle falls back to an
unnecessarily broad database lock because it cannot fully analyse a
complex query. Operators can use this metric to identify stream tables
that are causing more contention than expected.

---

## Scope

v0.31.0 is a medium-sized release. The improvements are internally focused
and invisible to users at the SQL level, but they make a measurable
difference at scale — particularly for deployments running hundreds or
thousands of stream tables.

---

*Previous: [v0.30.0 — Pre-GA Correctness & Stability Sprint](v0.30.0.md)*
*Next: [v0.32.0 — Reactive Subscriptions & Zero-Downtime Operations](v0.32.0.md)*