[postgis-devel] [postgis-users] ST_Distance with geography really slow: trees and caches

[Nicolás Lichtmaier]

I'm running PostGIS from Subversion trunk.

This is my first time looking at this code, so maybe I'm missing 
something, but from what I've seen I see this:

The new code needs to build some circular-area-tree structures. It tries 
to cache them. That cache is stored in the "generic cache" list which is 
in turn stored in fcinfo->flinfo->fn_extra. This seems to be cleared 
every time, so there's never a cache. And then the code in 
geography_measurement.c always falls back to a much slower code, here:

             /* Do the brute force calculation if the cached calculation
    doesn't tick over */
             if ( LW_FAILURE == geography_distance_cache(fcinfo, g1, g2,
    &s, &distance) )
             {


In any case... why not falling back to create the structures.. as 
geography_distance_tree does?

Thanks!

El 06/01/14 18:06, Paul Ramsey escribió:
> Let's talk on -devel.
>
> Could you point out which version you're looking at, first of all, in
> case there's differences between versions?
>
> Thanks,
>
> P.
>
> On Mon, Jan 6, 2014 at 7:35 AM, Nicolás Lichtmaier <nicolasl at wolfram.com> wrote:
>> I'm trying to solve a mistery (and I didn't know is I should post here or to
>> the the devel list)
>>
>> ST_Distance between complex polygons is very slow here, despite the work
>> done in http://boundlessgeo.com/2012/07/making-geography-faster/ .. It's
>> taking like 4 seconds.
>>
>> Looking harder into this I see there's a _st_distancetree(geo1, geo2) that
>> completes the task in 171 ms....
>>
>> It seems to me that the standard ST_Distance is not using the new "circular
>> bounding boxes" code...
>>
>> So I downloaded the source code and I saw that geography_distance_cache
>> always fails because GetCircTreeGeomCache always returns null. I see that a
>> cache is initialized and put into a "generic cache" array, but then is reset
>> to null in GetGenericCacheCollection when called from GetPROJ4SRSCache
>> beacuse "fcinfo->flinfo->fn_extra" is again null... (set in
>> MemoryContextAllocZero)
>>
>> Does this what I am saying make sense? =)
>>
>> How is this cache supposed to work?
>>
>> Thanks for any help!
>>
>> --
>> Nicolás.-
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users


-- 
Nicolás.-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140106/f7313df8/attachment.html>