From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Quentin de Metz" <quentin@de.me.tz>
cc: pgsql-novice@postgresql.org
Subject: Re: btree_gin, bigint and number literals
In-reply-to: <58782480-ab75-4416-a177-ccf91be288a9@app.fastmail.com>
References: <58782480-ab75-4416-a177-ccf91be288a9@app.fastmail.com>
Comments: In-reply-to "Quentin de Metz" <quentin@de.me.tz>
	message dated "Fri, 31 Jan 2025 18:02:13 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4037725.1738356169.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Jan 2025 15:42:49 -0500
Message-ID: <4037726.1738356169@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4037726.1738356169%40sss.pgh.pa.us>
Precedence: bulk

"Quentin de Metz" <quentin@de.me.tz> writes:
> On a multi-column GIN index over a bigint column and a text column, the =
query planner does not filter the index on the bigint column when a condit=
ion on this column is specified with a number literal.

Yeah, because "owner_id =3D 12" will use int84eq, which as you observe
is not supported by btree_gin's opclass.

> Would you be open to considering a patch to include the ALTER OPERATOR s=
nippet in the btree_gin install script, so that this works out of the box?

I'd be quite surprised if that "just works" without any corresponding
changes in the C code, because btree_gin.c only knows about applying
same-type-on-both-sides comparison functions.  (int8 vs int4 might
appear to work as long as you don't try very hard, but for example
it'd fail on 32-bit or big-endian hardware.)  If you feel like writing
a patch that actually takes care of the matter fully, step right up.

			regards, tom lane