Hello, thanks.
Solved. I think the problem was that I was downloading the file to a remote
disk (R: mapped to \\lanserver\data)
Another question: after exporting the whole planet (recently) to Postgres, what
is the size of the largest table created (which I presume will take up 80% of
the
* Juan Lucas Domínguez Rubio juan_lucas...@yahoo.com [2010-06-24 01:34 -0700]:
Another question: after exporting the whole planet (recently) to
Postgres, what is the size of the largest table created (which I presume
will take up 80% of the whole DB)?
I can't speak for the whole planet.osm
On Thu, Jun 24, 2010 at 4:34 AM, Juan Lucas Domínguez Rubio
juan_lucas...@yahoo.com wrote:
Hello, thanks.
Solved. I think the problem was that I was downloading the file to a remote
disk (R: mapped to \\lanserver\data)
Another question: after exporting the whole planet (recently) to
On 25 June 2010 00:28, Richard Weait rich...@weait.com wrote:
overall disk use ~ 130 GB and growing about 2.5 GB/week at the moment.
Is there a way to reduce this overhead without re-importing?
___
talk mailing list
talk@openstreetmap.org
From: Richard Weait rich...@weait.com
Subject:
Re: [OSM-talk] OSM Postgres table sizes (was: Failed to download 9.5 GB
planet)
To: talk@openstreetmap.org
Date: Thursday, June 24, 2010,
4:28 PM
On Thu, Jun 24, 2010 at 4:34 AM,
Juan Lucas Domínguez Rubio
juan_lucas...@yahoo.com
wrote
On Thu, Jun 24, 2010 at 10:39 AM, John Smith deltafoxtrot...@gmail.com wrote:
On 25 June 2010 00:28, Richard Weait rich...@weait.com wrote:
overall disk use ~ 130 GB and growing about 2.5 GB/week at the moment.
Is there a way to reduce this overhead without re-importing?
I'm not sure I
On 25 June 2010 04:37, Richard Weait rich...@weait.com wrote:
I'm not sure I understand your question.
Over time, the overhead increases, not just the amount of data.
You can import a bounding box or extract and have smaller tables.
You can import without --slim, if you have the hardware for
7 matches
Mail list logo
