Batch topology loading mode

[remic]

Data loading into Postgis Topology is insufferably slow. This is due to a conceptual limit of loading objects into topology one by one. Such behaviour is very good for limited changes, but very bad for massive creation.

We need a specific process to deactivate checkings, then load everything the batch way

[strk]

+1 for functions to add/drop constraints/foreign_keys

[strk]

FYI: I've been working on a function to "polygonize" correctly linked edges. Doesn't go all the way there (edge linking still has to be performed one by one) but may speedup the process significatively. I guess the interface for batch-loading would be the ISO ST_CreateTopoGeo function: ​http://postgis.net/docs/ST_CreateTopoGeo.html

The recent polygonization work (registerFaces) can be found here: ​https://git.osgeo.org/gogs/strk/postgis/src/batch-topo-all-in-ram

It exposes a TopoGeo_addLinestringNoFace (one by one) and a registerFaces (all in ram)

[strk]

Another idea: make foreign keys deferrable (right now they are built as non deferrable).

[strk]

For the record: latest version of the batch-topo branch is ​https://git.osgeo.org/gogs/strk/postgis/src/batch-topo

[robe]

Milestone renamed

[strk]

For the record the latest work in this direction is here: ​https://git.osgeo.org/gitea/postgis/postgis/pulls/28

[strk]

The ST_CreateTopoGeo batch-loading speedup entered the codebase and was tracked via #5670

What is still pending is a way to batch-load to a non-empty topology

[strk]

Deferred constraints are staging in ​https://git.osgeo.org/gitea/postgis/postgis/pulls/173

[strk]

And here's a PR to add/drop topology constraints: ​https://git.osgeo.org/gitea/postgis/postgis/pulls/176