Re: Allowing extensions to supply operator-/function-specific info
От | Tom Lane |
---|---|
Тема | Re: Allowing extensions to supply operator-/function-specific info |
Дата | |
Msg-id | 11051.1551139751@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allowing extensions to supply operator-/function-specific info (Paul Ramsey <pramsey@cleverelephant.ca>) |
Ответы |
Re: Allowing extensions to supply operator-/function-specific info
|
Список | pgsql-hackers |
Paul Ramsey <pramsey@cleverelephant.ca> writes: > On Mon, Feb 25, 2019 at 3:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> It's whichever one the index column's opclass belongs to. Basically what >> you're trying to do here is verify whether the index will support the >> optimization you want to perform. > * If I have tbl1.geom > * and I have built two indexes on it, a btree_geometry_ops and a > gist_geometry_ops_2d, and > * and SupportRequestIndexCondition.opfamily returns me the btree family > * and I look and see, "damn there is no && operator in there" > * am I SOL, even though an appropriate index does exist? No. If there are two indexes matching your function's argument, you'll get a separate call for each index. The support function is only responsible for thinking about one index at a time and seeing if it can be used. If more than one can be used, figuring out which one is better is done by later cost comparisons. regards, tom lane
В списке pgsql-hackers по дате отправления: