TimescaleDB 2.30.0 makes last-point lookups constant time

TimescaleDB's 2.30.0 release adds a planner scan called DeferredChunkAppend that changes how "what's the last reading from this sensor" gets answered. For anyone running that kind of last-point query over months of chunked time-series data, the scan cost used to grow with every new chunk, slowing dashboards and alerts as history piled up.

Previously, that kind of query expanded the whole hypertable during planning, which meant cost scaled with how many chunks existed. More history meant more chunks meant a slower plan, even when the answer sat in the most recent chunk.

DeferredChunkAppend leaves the hypertable unexpanded during planning and enumerates chunks at execution instead. Combined with the FIRST and LAST sparse index work already in TimescaleDB, a last-point query no longer scales with chunk count. It runs in constant time when the answer lives in the newest chunk.

It's on by default, controlled by enable_deferred_chunk_append.

The release also fixes a correctness bug. Chunks runtime-filtered under a parallel plan with an uncorrelated subquery could return wrong results. Anyone running that query shape could have gotten wrong answers with no warning, and anyone on an affected version should check their queries against it.