[OSM-dev] [OSM-talk] Bounding box

[Dave]

On 06/02/07, Raphaël Jacquot <sxpert at sxpert.org> wrote:
>
> Nick Hill wrote:
> >
> > Download the API from SVN. Point the API at the database. Run queries.
> > Make changes to the database. Find some fabulous new way of increasing
> > the speed with unlimited bounding boxes and no server slowdown. give us
> > all the figures. Convince everyone. I'll buy you a pint.
>
> that's understandable, but is not representative, as the planet doesn't
> have any history information.



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.

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.

Here are some of the things you can test without the history using MySQL,
ruby and a planet:

   - different database table engines
   - different databases (ie: postgres/postgis)
   - table partitioning
   - r-tree indexes
   - quad tree coordinates
   - 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.
   - different DB schemas
   - combinations of the above where they aren't mutually exclusive

I would find nice pretty graphs of these things very interesting, and look
forward to seeing them in the near future!

Thanks,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070206/21dda32f/attachment.html>