[postgis-devel] Recheck on Points broken
Regina Obe
lr at pcorp.us
Thu Jan 5 16:46:35 PST 2017
Okay I did some more snooping of the distance outputs.
Using this query that consistently fails:
create table test (geo geometry);
insert into test values
('0101000020E61000007D91D0967329E4BF6631B1F9B8D64A40'::geometry),
('0101000020E6100000E2AFC91AF510C1BFCDCCCCCCCCAC4A40'::geometry);
set enable_seqscan = false;
select *, '0101000020E610000092054CE0D6DDE5BFCDCCCCCCCCAC4A40'::geometry <-> geo , ST_Distance('0101000020E610000092054CE0D6DDE5BFCDCCCCCCCCAC4A40'::geometry, geo)
from test ORDER BY geo <->
('0101000020E610000092054CE0D6DDE5BFCDCCCCCCCCAC4A40'::geometry);
?column? | st_distance
-------------------+-------------------
0.331823813642119 | 0.331823813642119
0.55 | 0.55
(2 rows)
The issue seems to be with the second record that the approximate distance 0.5500000111921 is just a wee bit bigger than the actual distances.
Which as you said should never happen.
NOTICE: bbox2df_distance: (0.331818528656)
NOTICE: bbox2df_distance: (0.550000011921)
NOTICE: index returned tuples in wrong order. cmp: -1
Does this create beaming lights in your head?
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Tuesday, January 03, 2017 10:00 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] Recheck on Points broken
Are we 100% sure this is a float/double issue? The distance between two float boxes should always be *smaller* than the actual distance between two objects, since the float box extrema are always moved *away* from the original object when the float boxes are created. So from a "theoretical mechanics" perspective this shouldn't actually be the source of the problem.
>From a real world point-of-view, how could it still be the problem?
- maybe the box generation code has a short circuit for points which doesn't do the correct thing? Pretty sure it doesn't, but.
- something else?
P
On Tue, Jan 3, 2017 at 4:54 AM, Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:
>> Anyrate if there is nothing that can be done about ensuring index
>> distance is always less or equal to actual distance
> I remember we were all happy about having *real* distance with a more recent PostgreSQL. If that's not the case (as the user reports) we should try to find a way to provide both mechanisms.
> Two different operators, maybe ?
> --strk;
We've already got two different operators. We have <#> which doesn't use recheck and that's what I told the user to use, until we resolve this.
The thing is the <-> I think pretty much for all reasonable purposes returns the right order for points (and in fact in this case yields the same value and <-> I think in all cases it will).
So it's just the float4/float8 mess why it screws up and it Errors noisily in PostgreSQL land where we cannot control.
I hate telling people to if you have point / point use <#> and if you have others you can safely use <->. That's sooo unfriendly.
I think the best thing is just to not have point-point checks use recheck. Can we do that easily? That's what PostgreSQL point/point does.
That way we don't fall into the PostgreSQL box trap of
"Hey -- how come your index distance is bigger than your computed distance. What kind of monster are you? Screw you!"
Thanks,
Regina
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto: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/20170105/1649d3ab/attachment.html>
More information about the postgis-devel
mailing list