Re: BUG #12644: Planner fails to use available index with anything other than default operator - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #12644: Planner fails to use available index with anything other than default operator
Date
Msg-id 23433.1422138216@sss.pgh.pa.us
Whole thread Raw
In response to BUG #12644: Planner fails to use available index with anything other than default operator  (Jim@mcdee.net)
List pgsql-bugs
Jim McDonald <Jim@mcdee.net> writes:
> On 24/01/2015 15:01, Tom Lane wrote:
>> Nope, this doesn't work, never has, and will not in the foreseeable
>> future.  Index access is defined in terms of operators, not other
>> ways to access the same function; see

> Fair enough.  As a workaround in the meantime is it possible to create a
> custom operator that is recognised as being in the correct family/class
> so that it will use the index?

Not really, I'm afraid.  In the abstract maybe you could add such an
operator to an existing operator class; but in practice this will fall
foul of the unique indexes on pg_amop, which insist that there be
at most one operator per strategy per opclass.

However, there's more than one way to skin a cat.  I think you could
probably define such an operator that references an inlineable SQL
function that expands to the desired underlying operator, along the
lines of

create function my_jsonb_exists(jsonb, text) returns bool as
'select $1 ? $2' language sql immutable;

create operator ### ( procedure = my_jsonb_exists, ...

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #12644: Planner fails to use available index with anything other than default operator
Next
From: Erik Jones
Date:
Subject: Duplicate key existant/index visibility bug in 9.3.3