soop_asf_mt, soop_sst - slow on running BoundingPolygonAsGml3

[danfruehauf]

Running the following can take a few minutes:

select BoundingPolygonAsGml3('soop_asf_mt','soop_asf_mt_trajectory_map','geom',5);

Same is for soop_sst. The explain for the query (after looking at the definition of boundingpolygonasgm3) is:

"QUERY PLAN"
"Aggregate  (cost=4021594.00..4021594.01 rows=1 width=32)"
"  ->  Function Scan on create_grid_cells grid_cell  (cost=0.25..4021592.75 rows=500 width=32)"
"        Filter: (SubPlan 1)"
"        SubPlan 1"
"          ->  Limit  (cost=0.00..4021.58 rows=1 width=0)"
"                ->  Nested Loop  (cost=0.00..4021.58 rows=1 width=0)"
"                      Join Filter: (a.file_id = b.file_id)"
"                      ->  Seq Scan on visualisation_wms a  (cost=0.00..3609.99 rows=1 width=4)"
"                            Filter: ((st_makevalid(geom) && grid_cell.cell) AND st_intersects(st_makevalid(geom), grid_cell.cell))"
"                      ->  Seq Scan on deployments b  (cost=0.00..366.82 rows=3582 width=4)"

[danfruehauf]

@jonescc @lbesnard FYI

[jonescc]

Perhaps just using visualisation_wms to calculate the spatial extent would do @lbesnard

[danfruehauf]

@jonescc Can you confirm it is faster?

[jonescc]

Takes milliseconds to calculate using visualistation_wms

[danfruehauf]

@jonescc :+1:

@lbesnard Probably worth modifying the harvesters for that.

[jonescc]

Its a context param isn't it?

[danfruehauf]

Actually yes, it is...