2009/4/3 Stefan de Konink ste...@konink.de:
What I have seen using gzip and bzip2 on the fly decompression on 5x
raid0, only one CPU was busy decompressing and the actual tool had a cpu
time of .30. It was clear that first decompressing then running the tool
on an mmap file was faster.
Just
2009/4/4 Martijn van Oosterhout klep...@gmail.com:
Just reading this again made me realise that we could probably make
osm2pgsql faster for the common case just by forking and using
gzip/bzip2 to do the decompression in a separate process (i.e. another
CPU)... Not entirely sure how much you'd
Matt Amos wrote:
2009/4/4 Martijn van Oosterhout klep...@gmail.com:
Just reading this again made me realise that we could probably make
osm2pgsql faster for the common case just by forking and using
gzip/bzip2 to do the decompression in a separate process (i.e. another
CPU)... Not entirely
2009/4/4 Matt Amos zerebub...@gmail.com:
2009/4/4 Martijn van Oosterhout klep...@gmail.com:
Just reading this again made me realise that we could probably make
osm2pgsql faster for the common case just by forking and using
gzip/bzip2 to do the decompression in a separate process (i.e. another
El Jueves, 2 de Abril de 2009, Will Nordin escribió:
I am trying to convert the planet-090319.osm (approx 107GB) to gml. I've
tried the Java and Python solutions, but both end up thorwing OutOfMemory
exceptions.
Man, it's one-frakking-hundred gigabytes, how would it *not* cause OOM
errors?!
Hi,
Iván Sánchez Ortega wrote:
You should try splitting the planet with Osmosis first, then individually
converting each of the pieces to GML.
... but first make sure that the tools you wish to process the resulting
GML with are actually capable of handling that amount of data ;-)
Depending
2009/4/2 Stefan de Konink ste...@konink.de:
Iván Sánchez Ortega wrote:
El Jueves, 2 de Abril de 2009, Will Nordin escribió:
I am trying to convert the planet-090319.osm (approx 107GB) to gml. I've
tried the Java and Python solutions, but both end up thorwing OutOfMemory
exceptions.
Man,
Matt Amos wrote:
2009/4/2 Stefan de Konink ste...@konink.de:
Iván Sánchez Ortega wrote:
El Jueves, 2 de Abril de 2009, Will Nordin escribió:
I am trying to convert the planet-090319.osm (approx 107GB) to gml. I've
tried the Java and Python solutions, but both end up thorwing OutOfMemory
2009/4/2 Stefan de Konink ste...@konink.de:
Matt Amos wrote:
so you'd need to either store
all the node locations in ram or some external indexed format... which
is exactly what osm2pgsql does :-)
mmap the node table in array index form to disk, that will work because of
hole allocation,
Stefan de Konink wrote:
Does anyone have any timings on importing the current planet.osm in
PostgreSQL with any tool available? Using lets say 8GB of ram and
'typical' disk?
I don't have full numbers but I do have some figures which may be useful.
Early in January Jochen Topf did some
10 matches
Mail list logo
