[OSM-dev] disk size for planet osm import into PostGIS (on an SSD)?

[Akos Maroy]

Hi,

I'd like to inquire about the estimated disk size needed to import the 
planet osm file into PostGIS?


What I wanted to do is to import planet osm into a PostGIS that is based 
on a 512GB SSD (well, formatted and reported size: 459G, 480720592 
bytes). I did the import using osm2pgsql, using:

/usr/local/bin/osm2pgsql -d osm_world -s -C 5800 --hstore-all -K -v -G 
-m  planet-130620.osm.bz2


the end of the import is the following:

Completed planet_osm_roads
Creating osm_id index on  planet_osm_point
Creating indexes on  planet_osm_point finished
All indexes on  planet_osm_point created  in 10171s
Completed planet_osm_point
CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways USING gin (nodes)  
WITH (FASTUPDATE=OFF);
  failed: ERROR:  could not extend file "base/1602600/4948340.12": No 
space left on device
HINT:  Check free disk space.

Error occurred, cleaning up




of course I have more space on traditional HDDs, but my main point is to 
have the I/O intensive parts of the PostGIS database on the SSD. the OSM 
file to be imported is located on a traditional HDD (not on the SSD), 
and the osm2pgsql command is also issued from a prompt that resides on 
the HDD. the /tmp directory is not on the SSD either.

the SSD is formatted as ext4

would the planet OSM in general fit on such a disk?

are there optimization possibilities to decrease the required disk size 
for the import? maybe:

  * some temporary disk space is used during the import that could be
    moved from the SSD to the HDD?
  * some not I/O specific parts of the database files could be relocated
    to the HDD (and symlinked)?
  * some parts of the database could be omitted (like, I don't need the
    history, etc.)
  * maybe some tune2fs magic?


any pointers, ideas, etc. welcome,


Akos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20130627/858acbeb/attachment.html>