Re: Allowing extensions to supply operator-/function-specific info

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allowing extensions to supply operator-/function-specific info
Date: 2019-02-26 00:09:11
Message-ID: 11051.1551139751@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> On Mon, Feb 25, 2019 at 3:01 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jamison, Kirk 2019-02-26 01:08:30 RE: Timeout parameters
Previous Message Tom Lane 2019-02-25 23:41:17 Re: POC: converting Lists into arrays