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

[Paul Ramsey]

There's two things going on here potentially, either one of which
could account for your issue:

- The cache is truly never being built. I am dubious, but it does fit
your description. I need more info to believe that.
- The behavior of the cache logic is not optimal. As you note, the
behaviour when there is a cache miss (the current feature doesn't
match a previously encountered feature) is to run a brute force
computation. The assumption embedded in the logic is that building an
indexed structure and then running the calculation is more expensive
than just running the brute force computation, so we only build
structures when we've seen an object twice in a row. This assumption
may very will be wrong in the distance case in general and the
spherical distance case in particular.

P.

On Mon, Jan 6, 2014 at 1:17 PM, Nicolás Lichtmaier <nicolasl at wolfram.com> wrote:
> 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.-