-- pg_turbovec v1.20.1 -- CRITICAL PERF FIX: iterative_scan default off.
--
-- This file is a *reference mirror*. The authoritative install
-- script is generated by `cargo pgrx schema`.
--
-- Empty migration: this release changes a GUC's COMPILED-IN default
-- (turbovec.iterative_scan: relaxed_order -> off) and doc/test
-- fixes only. No new SQL objects, no wire-format change
-- (MetaPageData::version stays 5), NO REINDEX.
--
-- Why: PostgreSQL's reorder queue (IndexNextWithReorder in
-- nodeIndexscan.c) can only return a tuple early when the AM's
-- advertised order-by value for that tuple is exact. pg_turbovec
-- always advertises f64::NEG_INFINITY (opclass-agnostic safety), so
-- that condition is never met -- under the old default
-- (relaxed_order) the executor was forced to drive the AM's own
-- iterative refill schedule (probe-widening / k-doubling up to
-- max_scan_tuples) to completion on EVERY `ORDER BY ... LIMIT`
-- query, regardless of how small the LIMIT was. Measured on
-- SIFT-1M/128d IVF: ~2ms with iterative_scan=off vs ~900ms with the
-- old default relaxed_order -- a 450x tax paid by every
-- default-configuration KNN query since relaxed_order first shipped
-- in v1.8.0. Every benchmark in this repo explicitly set
-- iterative_scan=off, which is why this went undetected until an
-- a cloud VM frontier run used the untouched default.
--
-- If you rely on relaxed_order's under-return-avoidance for a
-- selective WHERE filter, opt back in with:
--   SET turbovec.iterative_scan = relaxed_order;
-- (session or postgresql.conf). See docs/PRODUCTION.md and
-- docs/UPGRADING.md.

-- (intentionally empty -- ALTER EXTENSION pg_turbovec UPDATE TO
-- '1.20.1'; is sufficient; the GUC default takes effect on the next
-- backend that reads it, no index rebuild of any kind required.)