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
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
Still no go. I actually tried a bunch of different selectivity functions too,
and the planner correctly used them to estimate the number of potential
returned functions, but in no case did the index actually kick in, no matter
how selective I made the operator appear.
P.
--
http://postgis.
On Wed, Sep 24, 2014 at 2:01 PM, Paul Ramsey wrote:
> If I build an index on the same table using the internal quad-tree ops, and
> use their operator, I do get an index scan.
What about when enable_seqscan = off?
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-gen
Hi all,
I continue to bang along towards a binding of the spgist api from a run-time
extension (postgis, in this case).
To avoid complication, I am actually not doing any postgis code at this point,
just copying the internal point quadtree implementation and seeing if I can get
it to turn over.
