[postgis-devel] Issue 19

[Mark Cave-Ayland]

Paul Ramsey wrote:

> http://code.google.com/p/postgis/issues/detail?id=18
> 
> Mark, you've upgraded this to 1.4, so we should discuss. Your comment in 
> the 8.4 block indicates you think we do need to re-check. I'm pretty 
> sure right now our re-check just testings the float4 boxes again, so it 
> doesn't accomplish anything. And I'm not sure our contract with users is 
> to be anything but inexact (but overdetermined) on index searches.
> 
> Now, I think Kevin has some use cases where the float4 round causes 
> issues. I guess "group by" for points, yes? I think that the use case of 
> "faster for large geometries" outweighs the use case of "group by for 
> points", but I could be wrong.
> 
> P.

It wasn't supposed to be like that, although re-reading it now I see 
that it comes across differently than was intended. At the end of the 
day, there needs to be a compromise between usability and performance - 
and while I was originally for the RECHECK to help beginners, we now 
have a reasonable body of evidence that shows we are seriously 
penalising performance on large databases. So given that Kevin has a 
work-around, it makes more sense to add a note to the documentation and 
make the change.

> PS - I see the recheck value getting set in the gist_consistent test, 
> but where does the recheck then occur, if we return true?

The RECHECK is performed by the executor; the query planner inserts an 
extra join filter condition to re-evaluate the geometry as the join is 
executed.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063