<br><br><div class="gmail_quote">On 17 December 2010 00:45, 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>Having done some test some time ago, having functions in pl/pgsql doesn't have much impact in terms of performance overall. The major impact is still by far the IO. In my environment, I partially resolved the issue by the fact that our search pattern in the query are going to be localized.<br>
I ended up writing a multithreaded component that would rearrange queries to stopped working in FIFO mode. The queries were rearranged by proximity and send to the database in that order, in order to maximize the effects that we got Postgresql caching the data from the first query. Depending on the type of load we were getting, this was giving us some non negligible boost, while in the worst case scenario, it was giving slightly less performance (due to the reorganizing of queries). <br>
I know that the OSM admins are looking into the replication from postgresql 9.0. There are still some little issues to be solved due to some temporary tables not usable on replicated database.<br><br>Emily Laffray<br>