Unnecessary flat-nodes with enough RAM about osm2pgsql HOT 8 CLOSED

We now have a very efficient RAM middle, which allows to import the whole planet on a machine with 128GB RAM. That's what should be used on machines with enough RAM to import a non-updateable database.

Can we close this issue as not relevant anymore?

from osm2pgsql.

How about literally allowing /dev/null instead of adding yet another option? Or would that be too obscure?

We'd have to disable ALLOW_LOSSY on the ram cache, so it fails if the cache is too small and chain get request right through. Not very difficult to do.

from osm2pgsql.

#668 may fix this if it makes --cache unnecessary because it's a mmapped file

from osm2pgsql.

@lonvia, did we ever test this? Perhaps there's a doc change needed.

from osm2pgsql.

If you mean /dev/null, that does not work. If you mean the mmapped file, you probably still need the space on the disk but it might never be written to disk if there is enough memory and we delete it early. I can't test that on my setup at the moment.

from osm2pgsql.

I was thinking of --slim --flat-nodes nodes.bin --cache 0, which then relies on OS caching for the mmapped file. But I guess there still is a use for a /dev/null equivalent

from osm2pgsql.

The cache is more compact for extracts, so yes. Flat nodes on the other side cannot accidentally run out of memory.

from osm2pgsql.

We should go about this in a different way: if --drop is given and no floatnode file, then osm2pgsql should only save the node locations in the DB that do not fit into the RAM cache. This has the same effect as requested in the original issue with the added bonus that it works even when the RAM cache is a little bit too small to keep all node locations.

from osm2pgsql.