On 25 June 2010 20:23, Chris Jones wrote:
> Any overhead is typically a percentage of the stored data for indexes
> and such, you cant just magically get rid of it!
I was under the impression that it was incremental data from minutely updates...
___
ta
On 24/06/10 19:44, John Smith wrote:
> On 25 June 2010 04:37, Richard Weait wrote:
>
>> I'm not sure I understand your question.
>>
> Over time, the overhead increases, not just the amount of data.
>
>> lose some large tables. But then you lose the ability to update
>> unless you do a
On 25 June 2010 04:37, Richard Weait 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 it, and
I di
On Thu, Jun 24, 2010 at 10:39 AM, John Smith wrote:
> On 25 June 2010 00:28, Richard Weait 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 understand your question.
You can import a
From: Richard Weait
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
wrote:
>
> Hello, thanks.
>
> Solved.
On 25 June 2010 00:28, Richard Weait 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
http://lists.openstreetmap.or
On Thu, Jun 24, 2010 at 4:34 AM, Juan Lucas Domínguez Rubio
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 Postgres,
> what is th
* Juan Lucas Domínguez Rubio [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 file (so this might be u
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 whol
9 matches
Mail list logo