[postgis-tickets] [PostGIS] #4686: Faster bbox access for PG12+

[PostGIS]

#4686: Faster bbox access for PG12+
-------------------------+---------------------------
 Reporter:  Raúl Marín   |      Owner:  Raúl Marín
     Type:  enhancement  |     Status:  assigned
 Priority:  medium       |  Milestone:  PostGIS 3.1.0
Component:  postgis      |    Version:  master
 Keywords:               |
-------------------------+---------------------------
 We currently have to ways to access the bbox of a geometry from "disk":
 - gserialized_get_gbox_p: Tries to access the bbox, if it doesn't exist,
 deserializes the geometry and calculates it.
 - gserialized_fast_gbox_p: Tries to access the bbox, if it doesn't exist,
 returns NULL.

 In both cases if the datum was toasted, it has been detoasted (which is
 expensive).

 I **think** (not tested performance impact yet) that there are multiple
 cases were we could benefit from following a different approach (similar
 to #4676):
 - Starting with the Datum.
 - Read the header only.
 - Check the bbox from the header. If available, return it (huge win for
 toasted value).
 - If we really want the bbox (first case), then if there is more data
 available in the datum* detoast it fully, deserialize it and calculate it.


 The possible benefits from this are the callers to those 2 functions,
 including the ANALYZE calls (`compute_gserialized_stats_mode`).

 * I'd say most of the time there isn't any more data to read. The header
 considers a 4d bbox, that is 8 floats (8*32b = 256bits), and the extended
 flags (64b, which are seldom used). This is enough space for a single 4D
 point or 2 2D points. In any case, we could artificially increase the size
 request for the header if we wanted to.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4686>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.