[OSM-dev] database growth on updated partial import

Stephan Knauss osm at stephans-server.de
Tue Aug 24 08:34:45 BST 2010

Frederik Ramm wrote:
> vacuum process is not enough (try a vacuum full and see if size goes 
> down; if yes, increase your max_fsm_pages).
After a few hours the connection broke. So not sure the vacuum actually 
completed. Looking at the table statistics it reports 26298 dead tuples 
and 5991057 live tuples.

So vacuuming would not reclaim that much space, right?

>> It seams to be planet_osm_ways growing. It also contains lots of ways 
>> that are completely outside the bounding box.
> Unsure why that can happen. The bbox filter is only applied to nodes 
> (because only they have a location). Maybe all created/modified ways are 
> imported even if they refer to non-existing nodes entirely?
That is what I fear. Can this check be done in osm2pgsql?

>> Would it be safe to delete rows with geometry outside the bounding box? 
> I think so, but the planet_osm_way table does not have a geometry. You 
> would have to write a query that eliminates those ways which have 
> dangling references to nodes I think. Sounds slow ;)
You're right about the geometry. I noticed by looking at the tags that 
the ways belong to a different part of the world.

But there is a "id" column. I thought I could match all ids that are not 
included in the _line _polygon _roads tables.

I guess this would be a sequential scan on the later tables and a index 
lookup on _ways. Will try this later.
Or does anyone have better ideas?

Still open question is whether this is a problem with the import of 
osm2pgsql. Are all changed ways added regardless of the bounding box?


More information about the dev mailing list