[postgis-devel] Btree operators

[Komяpa]

чт, 7 апр. 2016 г. в 17:39, Paul Ramsey <pramsey at cleverelephant.ca>:

> Speed is a benefit. Once you start down the road of = semantics, the
> question of "which equals" looms large. Spatial equality?
> Representational equality? Equality within a tolerance? Doing a string
> compare is basically the only one that doesn't impose a surprising
> cost, and it is, as you say, noisy.
>

The equality that is the same as string compare would be a lot less
surprising.
It shouldn't be slower than bbox equality with recheck for the case when
they're equal.


> WRT ordering, I did actually briefly have a z-ordering approach in
> place, but I cannot remember why I had to drop it: but I did. Shame
> about my memory on that.
>

So, maybe it's time for the new attempt, with at least FAQ entry if
everything breaks down? :)


> P
>
> On Thu, Apr 7, 2016 at 6:22 AM, Daniel Baston <dbaston at gmail.com> wrote:
> > I've seen plenty of users (including myself) confused by the = operator,
> > especially when it's implicitly accessed in cases like DISTINCT, DISTINCT
> > ON(), and GROUP BY.  The workaround, to serialize and do a string
> compare,
> > can really add a lot of noise to a query.  Are there benefits that come
> from
> > the current behavior of the = operator, besides the (high) value of
> > backwards compatibility?
> >
> > Dan
> >
> > On Thu, Apr 7, 2016 at 7:22 AM, Komяpa <me at komzpa.net> wrote:
> >>
> >> hey there,
> >>
> >> https://trac.osgeo.org/postgis/ticket/3521 floated nearby me and broke
> my
> >> heart.
> >>
> >> Can we have SELECT DISTINCT work for sure as a complete compare, not
> just
> >> bbox one?
> >>
> >> It also touches the topic of sorting the boxes - it seems now they're
> >> sorted by X, then by Y - which is usually a poor way to preserve spatial
> >> locality. Can we sort by z-order curve instead? just bit-mix all the
> >> coordinates: https://en.wikipedia.org/wiki/Z-order_curve - that will
> make
> >> painful voodoo stuff like ORDER BY
> >> ST_GeoHash(ST_Transfrom(ST_Centroid(geom),4326)) much cleaner and
> replace it
> >> with just CLUSTER (see
> https://github.com/openstreetmap/osm2pgsql/issues/208
> >> ).
> >>
> >> _______________________________________________
> >> postgis-devel mailing list
> >> postgis-devel at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/postgis-devel
> >
> >
> >
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160407/841f0f8a/attachment.html>