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
