On 10/13/2014 09:52 AM, Sven Geggus wrote:
Jepp. I already did something like this myself. A disadvatage of the
approach is, that there is no way to dump indexes, they have to be
re-created on the target machine while running pg_restore.
one of the reasons why I was working on a mysql output
Paul Norman wrote:
On 10/12/2014 2:49 PM, Ilya Zverev wrote:
Hi! Yesterday I had a simple task: there is a rendering server, which
is not to be minutely updated. So its PostgreSQL database doesn't need
temporary slim tables. But I cannot import an extract without
creating those, so basically I
Ilya Zverev i...@zverev.info wrote:
The solution is obvious: I rented a huge hourly-priced droplet,
installed postgresql and osm2pgsql there, imported a big OSM extract,
deleted slim tables and transferred database contents to said
rendering server.
Jepp. I already did something like this
On 10/13/2014 12:52 AM, Sven Geggus wrote:
I still think distributing sql updates for rendering databases in addition
to osm diffs would be a nice to have feature, because the state of the osm
database is of no interest to a rendering database. I never tried to
implement this though.
How I'd
Hi! Yesterday I had a simple task: there is a rendering server, which is
not to be minutely updated. So its PostgreSQL database doesn't need
temporary slim tables. But I cannot import an extract without creating
those, so basically I can import 3 times less data than possible.
The solution is
On 10/12/2014 2:49 PM, Ilya Zverev wrote:
Hi! Yesterday I had a simple task: there is a rendering server, which
is not to be minutely updated. So its PostgreSQL database doesn't need
temporary slim tables. But I cannot import an extract without
creating those, so basically I can import 3 times
6 matches
Mail list logo
