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  (Paul Ramsey <pramsey@cleverelephant.ca>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: POC: converting Lists into arrays
Следующее
От: "Jamison, Kirk"
Дата:
Сообщение: RE: Timeout parameters