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.
Add your support for this item by contacting us for a quote and discussion of the particular features you need.
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
The geodetic GEOGRAPHY operations are currently very CPU intensive, because they involved multiple trancendental math calls. Performance could be improved through caching of calculations, both at a low level (coordinates) and a high level (data structures).
The support for dimensions higher than X/Y is uneven as currently implemented. Most operations support clean handling of the Z dimension (but a few do not). A reasonable number of important functions do not support handling of the M dimension. This item would fix functions not handling higher dimensions.
A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.