Message-ID: <147ac793f2c3a9a57764fba84988a4b5e843443b.camel@cybertec.at>
Subject: Re: [PATCH] Add support function for containment operators
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Kim Johan Andersson <kimjand@kimmet.dk>, 
	pgsql-hackers@lists.postgresql.org
Date: Fri, 07 Jul 2023 13:20:41 +0200
In-Reply-To: <4e6efd382b3195eb7ea438b7219cc94d9399c0bd.camel@cybertec.at>
References: <94f64d1f-b8c0-b0c5-98bc-0793a34e0851@kimmet.dk>
	 <4e6efd382b3195eb7ea438b7219cc94d9399c0bd.camel@cybertec.at>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/147ac793f2c3a9a57764fba84988a4b5e843443b.camel%40cybertec.at>
Precedence: bulk

I wrote:
> You implement both "SupportRequestIndexCondition" and "SupportRequestSimp=
lify",
> but when I experimented, the former was never called.=C2=A0 That does not
> surprise me, since any expression of the shape "expr <@ range constant"
> can be simplified.=C2=A0 Is the "SupportRequestIndexCondition" branch dea=
d code?
> If not, do you have an example that triggers it?

I had an idea about this:
So far, you only consider constant ranges.  But if we have a STABLE range
expression, you could use an index scan for "expr <@ range", for example
Index Cond (expr >=3D lower(range) AND expr < upper(range)).

Yours,
Laurenz Albe