[OSM-dev] Table/Index Access (for SSD)

[Alan Mintz]

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+OSM at Earthlink.net>