[postgis-tickets] [PostGIS] #4674: lwgeom_cache doesn't live through not inline functions

[PostGIS]

#4674: lwgeom_cache doesn't live through not inline functions
------------------------+---------------------------
 Reporter:  Raúl Marín  |      Owner:  pramsey
     Type:  defect      |     Status:  new
 Priority:  medium      |  Milestone:  PostGIS 3.1.0
Component:  postgis     |    Version:  master
 Keywords:              |
------------------------+---------------------------
 While I was working on #4672, I noticed that the ST_AsGML cache wasn't
 working all the time (in fact it was working with geographies but not
 geometries).

 After adding some logs, it seems that if the function is inlined, the
 cache (installed in the parent memory context) lives for the next row, but
 if it isn't then you loose the cache and everything needs to be recreated
 again.


 Example that isn't inlined:
 {{{
 # explain (analyze, verbose) Select ST_AsGML(the_geom::geometry) from
 benchmark_7773a711c8441d4b494a51fd9feebeac7a9b9c734619398620293 limit
 4;NOTICE:  GetGenericCacheCollection not found
 NOTICE:  generic_cache not found
 NOTICE:  Cache not found. Expected: 4326 1. Found: 0 0 null
 NOTICE:  GetGenericCacheCollection not found
 NOTICE:  generic_cache not found
 NOTICE:  Cache not found. Expected: 4326 1. Found: 0 0 null
 NOTICE:  GetGenericCacheCollection not found
 NOTICE:  generic_cache not found
 NOTICE:  Cache not found. Expected: 4326 1. Found: 0 0 null
 NOTICE:  GetGenericCacheCollection not found
 NOTICE:  generic_cache not found
 NOTICE:  Cache not found. Expected: 4326 1. Found: 0 0 null
 QUERY PLAN
 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Limit  (cost=0.00..1.25 rows=4 width=32) (actual time=0.780..2.497 rows=4
 loops=1)
    Output: (st_asgml(the_geom, 15, 0))
    ->  Seq Scan on
 public.benchmark_7773a711c8441d4b494a51fd9feebeac7a9b9c734619398620293
 (cost=0.00..213260.58 rows=683833 width=32) (actual time=0.778..2.492
 rows=4 loops=1)
          Output: st_asgml(the_geom, 15, 0)
  Planning Time: 0.213 ms
  Execution Time: 2.534 ms
 (6 rows)
 }}}

 Example that is inlined:
 {{{
 # explain (analyze, verbose) Select ST_AsGML(3, the_geom::geometry) from
 benchmark_7773a711c8441d4b494a51fd9feebeac7a9b9c734619398620293 limit 4;
 NOTICE:  GetGenericCacheCollection not found
 NOTICE:  generic_cache not found
 NOTICE:  Cache not found. Expected: 4326 1. Found: 0 0 null
 NOTICE:  Cache FOUND. Expected: 4326 1
 NOTICE:  Cache FOUND. Expected: 4326 1
 NOTICE:  Cache FOUND. Expected: 4326 1
 QUERY PLAN
 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Limit  (cost=0.00..10.25 rows=4 width=32) (actual time=0.418..0.535
 rows=4 loops=1)
    Output: (_st_asgml(3, the_geom, 15, 0, NULL::text, NULL::text))
    ->  Seq Scan on
 public.benchmark_7773a711c8441d4b494a51fd9feebeac7a9b9c734619398620293
 (cost=0.00..1751884.83 rows=683833 width=32) (actual time=0.417..0.533
 rows=4 loops=1)
          Output: _st_asgml(3, the_geom, 15, 0, NULL::text, NULL::text)
  Planning Time: 0.152 ms
  Execution Time: 0.562 ms
 (6 rows)
 }}}


 I'm not sure if this affects more functions (probably anything doing
 indirect calls within SQL is susceptible to this behaviour) but it's
 indeed a PITA.

 Is there a query context that we can hook us to that lives for the whole
 duration of the query (instead of a transaction / function)?

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4674>
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.