At 2012-06-18 12:43, Lynn W. Deffenbaugh (Mr) wrote:
Very good. That's exactly what I was looking for. In my DB, I get:
planet_osm_point: 4369MB
planet_osm_line: 41GB
planet_osm_roads: 8530MB
planet_osm_polygon: 34GB
for a total of just under 88GB so a 120GB SSD should do the job. Now, to
see if I can figure out how to split up the DB to assign different tables
to different places....
Assuming you are going to process updates, you'll need some room to grow,
particularly with all this talk of importing building footprints ( :) ). I
don't know if someone has calculated the expected growth due to the edits
of the license redaction, either.
Also, is fragmentation an issue? While it's certainly less overhead than
seeking a physical disk, I would still expect that there is some overhead
(i.e. popping an address and size off the list and then retrieving it) for
each fragment. I'm not familiar with pgsql, but it might make sense to grow
the tables (and indices?) before copying so they are allocated as
contiguously as possible on the target drive if you're going to cut the
free space close.
--
Alan Mintz <alan_mintz+...@earthlink.net>
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
