On 06/02/07, <b class="gmail_sendername">Raphaël Jacquot</b> <<a href="mailto:sxpert@sxpert.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">sxpert@sxpert.org</a>> wrote:<div><span class="q">
<span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Nick Hill wrote:<br>><br>> Download the API from SVN. Point the API at the database. Run queries.<br>> Make changes to the database. Find some fabulous new way of increasing<br>> the speed with unlimited bounding boxes and no server slowdown. give us
<br>> all the figures. Convince everyone. I'll buy you a pint.<br><br>that's understandable, but is not representative, as the planet doesn't<br>have any history information.</blockquote></span><div><br><br>
I'm
guessing the majority of queries on the database don't ask for history
at the moment. And I'm also guessing that the majority of the
database's workload is requests rather than updates, especially in the
"insane" category being talked about. So it should be completely
possible to develop representative tests of various queries you'd like
to make, various indexing schemes, and various database engines. The
lack of history will have an effect on the insert commands only, where
the complexity isn't high as it works on single primitives being
inserted into a table.
<br></div><br></div>It should also be pointed out that the API's
current ability to provide history is very limited -- I'm just
mentioning this because it's currently impossible to do a history based
"insane" query.
<br><br>Here are some of the things you can test without the history using MySQL, ruby and a planet:<br><ul><li>different database table engines</li><li>different databases (ie: postgres/postgis)<br></li><li>table partitioning
</li><li>r-tree indexes</li><li>quad tree coordinates</li><li>different
API languages -- the code isn't that complex and could be transcribed
into python/java/whatever in not much time if you have some to spare.
I'm interested in how slow ruby really is.
</li><li>different DB schemas</li><li>combinations of the above where they aren't mutually exclusive<br></li></ul>I would find nice pretty graphs of these things very interesting, and look forward to seeing them in the near future!
<br><br>Thanks,<br><span class="sg"><br>Dave<br></span>