On Mon, Feb 25, 2019 at 4:09 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Paul Ramsey <pram...@cleverelephant.ca> writes: > > On Mon, Feb 25, 2019 at 3:01 PM Tom Lane <t...@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.
Ah, wonderful! New line of questioning: under what conditions will the support function be called in a T_SupportRequestIndexCondition mode? I have created a table (foo) a geometry column (g) and an index (GIST on foo(g)) and am running a query against foo using a noop function with a support function bound to it. The support function is called, twice, once in T_SupportRequestSimplify mode and once in T_SupportRequestCost mode. What triggers T_SupportRequestIndexCondition mode? Thanks! P