Yep, that was a typo (or, rather, an unpushed commit). And yep, the lack of a commutator was the problem. Thanks so much, it’s a huge relief to see it turning over properly :) now, onwards to actually doing the PostGIS implementation.
(On an semi-related note, if the spgist example had been in contrib, so it had to show a working instance of the SQL definitions of the operators and operator classes it would have been much easier to get started. For an API like spgist that is really meant for extension, having the example in contrib rather than core would help a lot.) Thanks again Tom! P. -- http://postgis.net http://cleverelephant.ca On September 24, 2014 at 8:24:02 PM, Tom Lane (t...@sss.pgh.pa.us) wrote: > Paul Ramsey writes: > > My C implementation is here > > https://github.com/pramsey/postgis/blob/spgist/postgis/gserialized_spgist_2d.c > > > > My SQL binding calls are here > > https://github.com/pramsey/postgis/blob/spgist/postgis/gserialized_spgist_2d.sql > > > > > Thanks to help from Andres Freund, I can now build an index based on my > > extension. However, > when I run a query using the operator(s) I have defined, the query never uses > my index, > it always sequence scans. > > > explain analyze select * from somepoints where > > '(5898.82450178266,7990.24286679924)'::point > = pt; > > (I assume that's a typo and you meant "... &=& pt") > > As stated, this WHERE clause cannot be used with the index: indexable > clauses in PG are always of the form "indexed_column operator something", > and you've written it the other way round. I gather that you think the > operator is commutative; but since you didn't declare that, the planner > doesn't know it can flip the clause around. Try adding "commutator = &=&" > to the declaration of the "point &=& point" operator. > > regards, tom lane > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
