Re: BUG #12644: Planner fails to use available index with anything other than default operator
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #12644: Planner fails to use available index with anything other than default operator |
| Дата | |
| Msg-id | 23433.1422138216@sss.pgh.pa.us обсуждение |
| Ответ на | BUG #12644: Planner fails to use available index with anything other than default operator (Jim@mcdee.net) |
| Список | 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 по дате отправления: