| 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: | Whole Thread | Raw Message | 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
| 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 |