Re: Allowing extensions to supply operator-/function-specific info - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allowing extensions to supply operator-/function-specific info
Date
Msg-id 11051.1551139751@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing extensions to supply operator-/function-specific info  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: Allowing extensions to supply operator-/function-specific info  (Paul Ramsey <pramsey@cleverelephant.ca>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: POC: converting Lists into arrays
Next
From: "Jamison, Kirk"
Date:
Subject: RE: Timeout parameters