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 по дате отправления: