Faster Estimated Extent Summary
Client software, particularly software that does coordinate system re-projection, requires the extent of a layer in order to integrate it with other layers. Spatial databases are generally slow at returning that information.
The current estimated_extent() function uses the histogram data collected by the "ANALYZE" database operation. Because ANALYZE collects statistics based on sampling, the estimates tend to be under-determined – smaller than the actual data extents. Clients compensate, by arbitrarily expanding the returned boxes, but this is non-optimal.
A better approach would be to read the head page of the spatial index and return that value, and to sample in the case where no index exists. Because the index page formats have been changing with updates to PostgreSQL, version-specific implementations would be required for past releases of PostgreSQL.
The result would be faster, more accurate estimated extents, which would improve all software clients using PostGIS.
Funding
This roadmap item is currently unfunded.
Get a quote now!
Get a quote or read more about core development to add your support to a road-map item.
Other Roadmap Items
Indexed Nearest Neighbor Searches
Currently nearest-neighbor searching is carried out with ad hoc tricks that expand a search radius until a candidate set is generated, then finding the closest value in the candidate set. A directly indexed approach would be optimally fast.
The PostGIS spatial index currently works exclusively in the X/Y plane. For data such as fleet tracking the “Z” or “time” dimension can serve as a useful query restriction. Higher dimensional indexes are needed.
Geometry matching function in PostGIS are currently biased toward exact matches. However, spatial data is often “logically equivalent but physically disjoint” – the machine representations are close but not exact even though the geometries represent the same features.