<div class="gmail_quote">Hi Stefan,<br><br>On Fri, Dec 17, 2010 at 11:45 AM, Stefan Keller <span dir="ltr"><<a href="mailto:sfkeller@gmail.com">sfkeller@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Brett<br>
<br>
Thanks very much for your detailed instructions.<br>
<div class="im"><br>
> In my experience the biggest limitation in performance is disk seeking,<br>
> rather than the amount of data returned.<br>
<br>
</div>If that's the bottleneck (or the amount of data returned before<br>
processing), then pl/pgsql or pl/python could help, since stored<br>
procedures are close to the data.<br></blockquote><div><br>Unfortunately I don't think that will help here.  In-database code can help if you have large numbers of queries, or need to sift through large amounts of returned data but neither of those apply here.  A fixed number of queries get executed per bounding box retrieval (I forget exactly, but less than 10 I think ...).  The early queries build up results in temp tables, and finally the contents of those temp tables are retrieved.  The overhead of queries being invoked outside the database server shouldn't add much in the way of overhead because the query issuance time is trivial compared to the amount of time the database then spends processing those queries, and only essential data is returned to Osmosis itself.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
If topology is an issue then perhaps the (future) topology data type<br>
could help (<a href="http://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology" target="_blank">http://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology</a><br>
). But I'm would test first the performance of relational (and hstore)<br>
structures.<br></blockquote><div><br>I have no idea about this one :-)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Finally, this sounds really like an postgres optimization task, when<br>
you speak of several days for full planet indexing.<br></blockquote><div><br>Keep in mind that there are over 800 million nodes now, and something like 70 million ways.  To build indexes on those rows, and then completely re-layout the data to be grouped geographically is always going to be time consuming.  I did spend a bit of time tweaking up the PostgreSQL tuning parameters to the point where further tweaks made little change.  I'm sure further improvements are possible, but without improving the disk subsystem underneath it I think the gains will not be that great.<br>
<br>More than happy to be proven wrong though ;-)<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
And finally optimization: I think this begins with the whole db<br>
architecture: I heard about a typical architecture, where there is a<br>
master and a slave disk: The master gets updated by the diffs, the<br>
slave is being replicated (postgres 9.0 can do that now!) and indexed.<br>
=> Seems to be a case for our Postgres/PostGIS gurus :-><br></blockquote><div><br>Sure, once you get into database level replication there's lots of things you can do to improve performance.  A single-master, multi-slave layout can provide near linear speed ups for read-only queries.  Of course it requires lots of hardware, and administrative overhead too ...<br>
</div></div><br>For reference, I measured the following times when setting up a full planet.<br>Raw Data Import: 18 hours, 34 minutes<br>Index Creation: 22 hours, 32 minutes<br>Clustering: 39 hours, 40 minutes<br><br>Cheers,<br>
Brett<br><br>