[postgis-devel] Caching Double-based Boxes

[Paul Ramsey]

KNN is a red herring: we're not going to change the index itself off
of floats; KNN ordering on boxes is always going to be a huge
approximation anyways.

What I'm missing here is any feedback on how my experimental branch
*works*, namely, is it still fast enough?

http://svn.osgeo.org/postgis/spike/pramsey/doublebox

Without Mark here to sing the praises of double boxes, it feels like
nobody cares enough for this to move forward, except maybe strk,
though he has mostly patched up the implementation problems with boxes
not being determinstic by sticking box rounding in various locations
around the code base. Which is too bad, because I spent a day on it.
But it's a hard-to-quantify improvement. It makes some things more
clear, since the lwgeom->bbox is more consistent. It'll also make the
ST_Extent aggregate marginally faster (because ST_Extent() can use the
cached boxes without guilt).

P.

On Fri, Nov 25, 2011 at 12:17 AM, Nicklas Avén
<nicklas.aven at jordogskog.no> wrote:
>
>> > There is nothing that points to the index key from the geometry? Is it
>> > so. It is the same reason we can't get the extent from a table from the
>> > index?
>>
>> I'd think you could, altought not easily.
>>
>
> interesting
>
>> But the main reason why you don't want to do that is that you don't
>> want to be _forced_ to have an index in order to process values.
>> Note that Geometry values could also be literal, never touching a table.
>>
>
> Yes, but if the geometry is literal the extra cost of calculating the
> bbox seems very very small. That calculation could in that case be done
> when building a geometry from text. Then all coordinates is traversed
> anyway.
>
> If the index would be the only place where the boxes was stored/cached
> it would just mean that without an index the boxes will have to be
> calculated each time.
>
> If this would be possible I will vote for that in PostGIS 3 :-)
>
> /Nicklas
>
>
>
>
>> --strk;
>>
>>   ()   Free GIS & Flash consultant/developer
>>   /\   http://strk.keybit.net/services.html
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>