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

On Mon, Feb 25, 2019 at 3:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > Looking at the examples, they are making use of the opfamily that
> > comes in SupportRequestIndexCondition.opfamily.
> > That opfamily Oid is the first one in the IndexOptInfo.opfamily array.
> > Here's where my thread of understanding fails to follow. I have, in
> > PostGIS, actually no operator families defined (CREATE OPERATOR
> > FAMILY). I do, however, have quite a few operator classes defined for
> > geometry: 10, actually!
>
> Yes, you do have operator families: there's no such thing as an operator
> class without a containing operator family, and hasn't been for quite
> a long time.  If you write CREATE OPERATOR CLASS without a FAMILY
> clause, the command silently creates an opfamily with the same name you
> specified for the opclass, and links the two together.

OK, starting to understand...

> > Some of them (gist_geometry_ops_2d, spgist_geometry_ops_2d ) use the
> > && operator to indicate the lossy operation I would like to combine
> > with ST_Intersects.
> > Some of them (gist_geometry_ops_nd, spgist_geometry_ops_nd) use the
> > &&& operator to indicate the lossy operation I would like to combine
> > with ST_Intersects.
>
> Right.  So the hard part here is to figure out whether the OID you're
> handed matches one of these operator families.  As I mentioned (in
> the other thread [1], maybe you didn't see it?) the best short-term
> idea I've got for that is to look up the opfamily by OID (see the
> OPFAMILYOID syscache) and check to see if its name matches one of
> the above.  You might want to verify that the index AM's OID is what
> you expect, too, just for a little extra safety.

I read it, I just didn't entirely understand it. I think maybe I do
know? I'm reading and re-reading everything and trying to build a
mental model that makes sense :)

Back to SupportRequestIndexCondition.opfamily though:

> 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?

> Sure, but that was a pretty lame way of getting the optimization,
> as you well know because you've been fighting its deficiencies for
> so long.

Hrm. :) I will agree to disagree. This is an intellectually
interesting journey, but most of its length is quite far removed from
our proximate goal of adding realistic costs to our functions, and the
code added will be quite a bit harder for folks to follow than what it
replaces.

Reading your code is a pleasure and the comments are great, it's just
a hard slog up for someone who is still going "Node*, hm, how does
that work..."

ATB,

P

> Perhaps at some point we'll have some infrastructure that makes this
> less painful, but it's not happening for v12.
>
>                         regards, tom lane
>
> [1] https://www.postgresql.org/message-id/22876.1550591107@sss.pgh.pa.us