Monthly Summary: Cross-type integer operator support for btree_gist (May 2026)

Overview

This thread proposes adding cross-type operator family entries to btree_gist for integer types (int2, int4, int8), addressing a long-standing usability gap where GiST indexes silently fail to match index quals when the query datum type differs from the indexed column type.

The Problem

When a query like WHERE camera_id = 1189 is issued against an int8 column, the parser resolves 1189 as int4 and selects =(int8, int4) from pg_operator. For B-tree indexes, cross-type operators are registered in the opfamily, so op_in_opfamily() succeeds. For gist_int8_ops, only same-type =(int8, int8) is registered, causing the planner to silently drop the qual from index consideration.

This is particularly damaging for multi-column GiST indexes (e.g., GIST (scalar_col, range_col)) used for exclusion constraints and range overlap queries, where the scalar equality is typically the most selective predicate. ORMs and parameterized queries routinely send int4 literals, creating a silent performance cliff.

Proposed Design

• Operator registration: Extend gist_int{2,4,8}_ops with cross-type entries for all six btree strategies plus KNN distance (<->) via ALTER OPERATOR FAMILY ... ADD OPERATOR.
• Execution-time dispatch: Rather than registering combinatorially many cross-type support functions (which would conflict with amvalidate constraints), the proposal uses a per-opclass static dispatch table keyed on the subtype OID:

typedef struct gbt_subtype_info {
    Oid         subtype;
    gbt_cmp_fn  lt, le, eq, ge, gt;
    gbt_dist_fn dist;
} gbt_subtype_info;

• Backward compatibility: No change to key storage format; existing indexes don't need REINDEX. Same-type paths preserved when subtype == InvalidOid.

Open Design Questions

1. Whether reusing btree's existing cross-type comparison functions (btint48cmp, etc.) via amproc lookup would be cleaner than a hand-rolled dispatch table.
2. Whether gistvalidate() needs adjustment to avoid warnings about operators lacking matching support procs.
3. KNN distance overflow safety for cross-type subtraction.
4. Whether a framework-level fix (teaching GiST to look up cross-type comparisons generically) would be preferable to per-opclass tables.

Current Status

The thread remains an initial RFC with no patch posted and no community response. The author bumped the thread once during the month to draw attention, but received no feedback from committers or reviewers. The proposal is still awaiting its first substantive review.