[postgis-users] No index usage on geography query plan?
Paul Ramsey
pramsey at opengeo.org
Tue Jun 1 08:44:22 PDT 2010
Bounding cube you mean? Could do. The problem with that is, it turns
out that computing the bounding cube is actually the most
computationally intensive part of the geography code! So we don't
really want to do that for every edge of a shape. My approach is to
use "bounding circles" for each edge. I haven't given any thought to
whether they would be useful in the large for disk-based indexes (and
we have, in any event, a perfectly workable bounding cube
implementation), but for the in-memory problem they seem to make
sense.
P.
On Tue, Jun 1, 2010 at 11:38 AM, Martin Davis <mbdavis at refractions.net> wrote:
> Perhaps it could use an in-memory bounding prism index? You're using a
> disk-based one used for geography types, right?
>
> Paul Ramsey wrote:
>>
>> On Mon, May 31, 2010 at 10:27 PM, Paragon Corporation <lr at pcorp.us> wrote:
>>
>>
>>>
>>> On that thought. Remember how geometry intersects performance
>>> significantly
>>> increased with prepared geometry algorithm, are we using that same kind
>>> of
>>> prepared geometry logic for geography.
>>>
>>
>> No, we are not. The algorithm is currently brute force O(nm). My ideas
>> are very similar to the prepared geometry approach, but with some
>> changes necessary to work in spherical land (like, what are the index
>> leaves? not rectangles...)
>>
>> P.
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
More information about the postgis-users
mailing list