Re: [PATCH] btree_gist: add cross-type integer operator support for GiST

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.