Hi Alexander, On July 4, 2026, Alexander Nestorov wrote: > Attaching v6, rebased on top of a8c2547e.
Sorry it took me so long to get back to this. It was way to hot summer. I also think the patch is Ready for Committer. I have a few comments on the tests and documentation. The three main indexes in int_crosstype.sql each occupy just one page with the default block size, so they don't exercise the internal-page comparisons or distance bounds. Could we increase the data set to cover those too? I compared cross-type scans against seqscans on larger indexes and found no discrepancies in the cases I checked. Disabling seqscan and bitmapscan doesn't ensure that each predicate becomes an Index Cond. I removed the (int2, int4) strategy 1 entry from gist_int2_ops, and the corresponding count(*) query still returned 150: it used a full index-only scan with a Filter. Maybe extend the existing EXPLAIN coverage to more type/strategy combinations, checking that the conditions appear as Index Cond? That would test the intended behavior directly. We'd want plans that are stable across the buildfarm, though I don't see an obvious source of variation in these simple cases. Finally, the documentation says the integer distance operator computes in float8. That is the GiST distance support function; the SQL <-> operator still returns an integer and can report overflow. Could we describe the precision limitation specifically as a property of KNN index scans? Thank you! Best regards, Andrey Borodin.
