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

On Mon, Feb 25, 2019 at 4:09 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

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