Hi, I started the full planet import, and after a week of work the job was ALMOST done, failed during building indexes after the import was probably done, but the harddrive run out of space. 1) Is there a way how I can just rebuild the indexes without reimporting the whole set? By running commands directly in PGSQL I guess? Where? How? (i know how to use command line sql tool, but not skilled in PGSQL, just MySQL) 2) I did the import with autovacuum=off. Is there any way I can run it now to save some additional space? Here is the docker log.
Postgres log from within the docker:
Thank you! Radek asked 08 Feb '21, 13:32 Palalet |
A typical osm2pgsql 1.4 run would create these indexes:
You can probably just run these commands and they will simply fail where the index already exists. After that your database should be good to go, but remember that many map styles will require the creation of additional indexes for performance. You can switch on autovacuum before running the above commands if you want. It is unlikely to save space though. If you have a world-wide database, the planet_osm_ways_nodes index can easily use 200 GB of space. osm2pgsql 1.4 has a somewhat experimental feature where it allows you to reduce the size of that index at the cost of a little performance degradation during data updates (see option Of course if you don't need data updates at all then you can save a lot of space by dropping the tables answered 08 Feb '21, 13:45 Frederik Ramm ♦ thanks, will run the indexes and see what happens :) I do not plan to update it way too often, I rather need some basic map data source for my other work, no need to be 100% up to date. Didnt expect this to grow up to some 600Gb during the work, and I do not want to loose one week of procesing :) This is too much new technologies for me, appreciate your help!
(08 Feb '21, 14:12)
Palalet
well, I am unable to finish the task :( I did most of the indexes, but when I run the CREATE INDEX planet_osm_ways_nodes_idx ON public.planet_osm_ways USING gin (nodes) WITH (fastupdate=off); command, I get into trouble. The table is 160Gb, and running the index command takes up another 280Gb of space, before I had to kill it just before I run out of space again. Is this normal, that building the index takes x times more space than the original table? I tried to have them on separate tablespaces, one for data, one for index, but no help, it just eats up all available space :(
(13 Feb '21, 20:20)
Palalet
Yes, this is normal. I suggest to do what I said above under "of course if you don't need..." - just drop the tables required for updates, and don't create the planet_osm_ways_nodes index at all. You'll be fine for rendering, and you can worry about loading new data later. Your disk is too small for running a continuously updated planet. (Unless, perhaps, you try the experimental osm2pgsql option also mentioned above, or maybe try a zfs compressed file system.)
(14 Feb '21, 11:41)
Frederik Ramm ♦
thanks, I will do it as you say, I cannot keep up with this space consumption :) - the table is 160Gb, while the complete index (yes, I made it after all) is 321Gb, which is utter nonsense :( so it would need some 800Gb+ to do the whole import
(15 Feb '21, 06:47)
Palalet
btw, is there a documentation which table contain what, what is their purpose? Where can I get the information which tables do I need just for the render and for the import? Also, not sure what role plays the flatnodes file, you mentioned I can delete it, so I guess is is some "temporary table" that is created during the transformation from the OSM file to final Postgres tables?
(15 Feb '21, 07:57)
Palalet
|