Andrea Aime wrote:
> So I was wondering, is there any opportunity to run a blazing fast pre-query 
> against
> the index that will tell me whether joining/subquerying into the rtree is 
> going to be a win, or not?

Each node in an R-tree index stores the coordinates of the leaf objects/child 
nodes;
see <https://stackoverflow.com/a/25242162/11654> for how to get this 
information.
To get the index extents, combine the extents of all entries in the root node.

> Also, while I'm here, in PostGIS there is an option to cluster a table along 
> the spatial
> index, in order to reduce IO when the spatial index is the main access driver 
> (which is often
> the case in geographic information systems). I looked at tables with no 
> rowids, but
> it does not seem like a way to do it (spatial index not being suitable for 
> primary key).
> Anything else that could be done here?

For a static table, you could order the rows along a space-filling curve.
For a dynamic table, you would have to replace the R-tree with something else
(<https://en.wikipedia.org/wiki/Hilbert_R-tree>), which would no longer be 
portable.


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to