0.16.0 GA Verification

0.16.0 GA verification

A focused round on the shipped 0.16.0 release before moving to 0.17 — re-verifying the specific fixes that failed or were partial across the release candidates, and quantifying the split-pruning win that RC1 could only show as a plan shape.

Verdict: 0.16.0 GA is sound — clear to move to 0.17. All three tracked fixes hold: #2806 split pruning, #2807 UDT parse, and #2815 collection-column exposure. Split pruning delivers a measured −18% p50 latency and −4× coordinator CPU on isolated keyed reads. One residual — structured decode of UDT values inside collections — is a natural 0.17 follow-up, not a GA regression.

Open the full report →

The report is a self-contained two-view dashboard:

• Verdict — the fix scorecard, split-pruning latency differential, and the UDT-collection residual.
• RC1 → GA comparison — what moved between the first release candidate and the shipped release, round-over-round throughput, and the dimensions GA did not re-run.

Fix re-verification — RC1 → GA

Fix	0.16.0-rc1	0.16.0 GA
#2806 / #2679 split pruning	Inert — 13 splits on/off, no benefit	Fixed — 1 split, −18% p50, −4× CPU
#2807 UDT keyspace-qualified parse	Parse crash (code: Char), tables unreadable	Fixed — all UDT tables query
#2349 scalar frozen<udt> decode	Blocked behind the parse crash	Verified — {street, zip} readable
#2815 list<frozen<udt>> silent drop	Column absent (data-loss-class, rc2)	Symptom fixed — column present; raw bytes, not yet structured

Split-pruning perf (the headline)

RC1 could only show that pruning didn’t fire (13 splits on and off). GA both fires it and quantifies the win, measured from Trino’s own server-side stats over 60 samples per mode:

Isolated WHERE key = ?	splits	p50	coordinator CPU p50
pruning ON	1	152 ms	2 ms
pruning OFF	13	185 ms	8 ms

Under a 32-thread loadtest, steady-state throughput is unchanged (~33 qps both modes — the ceiling is the known fan-out skew #2680, not split count), but pruning ON has a much faster cold ramp and a tighter p99 tail because 13× fan-out is expensive to warm.

The one residual (0.17 candidate)

list<frozen<udt>> columns are no longer silently dropped — the data-loss symptom that #2815 tracked is fixed. But the elements come back as array(varchar) of raw serialized UDT bytes (verified correct and complete field-for-field against sstabledump), not a structured array(row(...)). So the data is reachable; the deeper in-collection structured decode (#2349’s further target) is the natural next step for 0.17 — not a GA blocker, and strictly better than rc2 where the column vanished entirely.

Run metadata: flight v0.16.0@sha256:74b12ccd (multi-arch INDEX; amd64 a45cac03 / arm64 f2f78d0b; also latest) · connector 0.16.0 (Maven Central) · Trino 481 · Cassandra 5.0.8 RF=3 · 3× i4i.xlarge · ~2.5M partitions/node · 2026-07-23. GA was a targeted perf + fix re-verify; the multi-hour soak / integrity / abort-taxonomy dimensions from the RC1 round were not re-run.