[OSM-dev] Updated simplified osm2pgsql database dump available

Paul Norman penorman at mac.com
Thu May 26 00:10:27 UTC 2016


On 5/25/2016 2:32 PM, Sven Geggus wrote:
> I have always been wondering if it would be possible to get rid of the
> special tables used for the sole purpose of keeping the rendering database
> up-to-date by using a scheme like this:
>
> osm2pgsql database with special tables  -> some psql replication scheme
>
> --> many slave databases without special tables kept up-to date using psql
>      some replication scheme
>
> This would have the advantage of a lower storage foot-print (only 4
> rendering tables left).

You'd still have the full storage footprint on one machine, it just 
helps with the requirements on your read-only replica slaves.

This can be done a few ways right now

- pglogical or trigger-based (e.g. slony) replication

Streaming replication doesn't work here since it replicates the entire 
cluster including slim tables

- PostgreSQL FDW magic

It should be fairly easily to post-import move the rendering tables to 
another cluster and use any replication method with that cluster.

- Allow connection information to be set per-table in osm2pgsql

This may be possible with the multi- backend. Adding it to all the 
backends shouldn't be too hard as osm2pgsql already uses independent 
connections for each table. The slim tables and rendering tables could 
then be directly placed on databases on different clusters

What is not possible is to centralize this. When doing updates what goes 
to the rendering tables depends on the osm2pgsql style, so your 
rendering table updates will not be the same as other people with a 
different style.





More information about the dev mailing list