[postgis-devel] Recheck on Points broken

[Regina Obe]

Nope not 100% sure was just a guess based on what Robert Haas said and my assumption that we don't generate boxes for points? 

I thought we don't cause it's just baggage, which means we are using the point where as in other cases it is a box distance.

 

I did try to put a sniffer on where it's measuring distance adist[i], bdist[i] around 396 but always got a backend crash.

 

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/executor/nodeIndexscan.c;h=3143bd94ec4499fba94b41693538b785c4b32e6c;hb=HEAD#l396

 

372 static int

373 cmp_orderbyvals(const Datum *adist, const bool *anulls,

374                 const Datum *bdist, const bool *bnulls,

375                 IndexScanState *node)

376 {

377     int         i;

378     int         result;

379 

 380     for (i = 0; i < node->iss_NumOrderByKeys; i++)

381     {

382         SortSupport ssup = &node->iss_SortSupport[i];

383 

 384         /*

385          * Handle nulls.  We only need to support NULLS LAST ordering, because

386          * match_pathkeys_to_index() doesn't consider indexorderby

387          * implementation otherwise.

388          */

389         if (anulls[i] && !bnulls[i])

390             return 1;

391         else if (!anulls[i] && bnulls[i])

392             return -1;

393         else if (anulls[i] && bnulls[i])

394             return 0;

395 

 396         result = ssup->comparator(adist[i], bdist[i], ssup);

397         if (result != 0)

398             return result;

399     }

400 

 401     return 0;

402 }

 

You will probably have much better luck since I was just fumbling my way thru the code.

 

Thanks,

Regina

 

 

 

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/20170103/dfbc3e27/attachment.html>