[postgis-devel] Re: geometry stats

[strk]

m.cave-ayland wrote:
> Hi strk,
> 
> Fantastic! A 'working' implementation of the stats collector already :)
>  
> > Taking a look at the code it seems the the index overlap 
> > function is box_overlap taken from external source, while  
> > sequencial scan uses geometry_overlap(). It might be better 
> > to get the full control over geometry operations (they might 
> > have changed something inthe box containment funx).
> 
> Yeah I think this has been well discussed already (see the thread
> http://postgis.refractions.net/pipermail/postgis-users/2004-February/003
> 961.html)
> 
> The way to test this would to be to try your same && query firstly using
> the index scan on a small number of tuples and verifying the results.
> Then peform the same query after typing SET ENABLE_SEQSCAN = 'f' and
> compare the results. If they are different then the implementation of
> box_overlap() is not the same as geometry_overlap() and this could be
> the problem you are seeing. I must admit that I would be quite surprised
> if the overlap() operator were broken this late in the game.
> 
> Looking at the comments in postgis_estimate.c, do you really get
> different query results when uncommenting your 'selectivity = 0.9'? Is
> this true if you try different values, say from 0.1 to 0.9?

Yes, box_overlap() is not the same as geometry_overlap().
There are no traces of box_overlap() in postgis code though,
so the late broke might depends on external factors.

> I suppose the other possibility is that some memory is being overwritten
> where it shouldn't be. I've had another quick look at your new code and
> the only thing I've noticed at first sight is that PostgreSQL passes
> float4 values by reference(!) and not by value which may cause the
> get_attstatlot()/free_attrstatslot() not to handle memory as they
> should. Then again I would expect this to have been more likely to seg
> fault rather than upset the query....

I actually get a random segfault, isn't this a get_attstatslot bug, anyway ? 

> I'm currently working to tight deadlines (both in and out of work) which
> means I don't have as much time as I like to experiment with this. I
> hope that in a week's time I shall have time to look at this in more
> detail.

I guess I'll be waiting for you on this :)

--strk;