[postgis-devel] Re: geometry stats

[strk]

dblasby wrote:
> I dont think there's ever been a report of '&&' (overlap) being broken.

I've seen with my eyes different result sets when using sequencial
scan vs index scan. The results became the same when changing
the call to box_overlap with a call to pgbox_overlap (made coying
from geometry_overlap.

> I dont think the original postgresql rtree implementations 
> (rtree_box_overlap()) are incorrect (the postgis ones are based on them 
> and I checked them for mistakes).
> Its more likely in the rtree_internal_consistent() function. 

rtree_internal_consistent() calls pvbox_overlap (previoulsy box_overlap)
for both RTContainedByStrategyNumber and RTOverlapStrategyNumber.
Could this be the problem ?

> We should 
> test oleg and teodora's polygon gist rtree implementation to see if it 
> correctly handles index searches like "@@" (etc).  Then we can have them 
> check it out and patch our implementation since its pretty much 
> *exactly* like theirs.

rtree_internal_consistent() calls *actually* theirs (apart from
pgbox_overlap just introduced).

> I'd like to see this fixed, but its a very rarely used feature to put 
> too much work into fixing where they can do equivelent queries like:
> 
> SELECT * FROM <table> WHERE the_geom && <box> AND 
> geometry_contains(<box>, the_geom) AND contains(<box>, the_geom);

Again, the bug I've seen was on the the_geom && <box> alone.
I don't have notice of other bugs... but I can suppose there
are other cases. We can just wait for bug reports and take no
further step now.

> dave

--strk;