>> If things are out of order, why isn't just going to was_exact = false >> good enough? >> >> I'm not sure if the mistake is in our PostGIS code or something in >> PostgreSQL recheck logic. >> If I change the elog(ERROR ...) to a elog(NOTICE, the answers are >> correct and sort order is right. >> >> Under what conditions would cmp return less than 0? I tried following >> the code in cmp_orderbyvals, but got lost and trying to put elog >> notices in to see what the distance is returning (I probably did it >> wrong), just ended up crashing by backend.
> cmp would return 0 if the estimated distance returned by the index AM were > greater than the actual distance. > The estimated distance can be less than the actual distance, but it isn't > allowed to be more. See gist_bbox_distance for an example of a "lossy" > distance calculation, and more generally "git show > 35fcb1b3d038a501f3f4c87c05630095abaaadab". >-- >Robert Haas > EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company Did you mean would return < 0 ? Since I thought 0 meant exact and not where it's Erroring? I think for points then maybe we should turn it off, as this could just be floating point issues with the way we compute the index. That would explain why it doesn't happen for other cases like polygon / point in our code or polygon /polygon in our code since the box box distance in our code would always be <= actual distance for those. So maybe the best course of action is just for us inspect the geometries and if both are points just disable recheck. It's still not quite clear to me even looking at that git commit, why those need to error instead of going thru recheck aside from efficiency. Thanks, Regina -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
