[OSM-dev] Too many slow queries in db

80n 80n80n at gmail.com
Tue Sep 4 09:35:22 BST 2007

On 9/4/07, Tom Hughes <tom at compton.nu> wrote:
> In message <20070904091233.p25hyf9pcg80goww at webmail.systemed.net>
>         Richard Fairhurst <richard at systemed.net> wrote:
> > Tom Hughes wrote:
> >
> >> The issue is having a usable database once the data is in, not getting
> >> it in there.
> >
> > It's only one very very little part of the problem, but we could move
> > GPS traces to a different box.
> Not trivial in rails, but I believe it is possible.

I don't understand why rails would be a constraint.  If you move the *whole*
GPX solution to, say, gpx.openstreetmap.org then you have a completely
separate rails instance as well.

In the short term, just turn off the whole GPX thing if it's slowing down
the API.  We can live without it for a while.

I don't however
> think that it will help much. In the short term it will probably mean
> the gps_points table can be cached better which will help but it won't
> get round the major problem of the indexes not being able to accurately
> locate the desired points or of lock contention with the import daemon.
> What we need to do is a combination of looking at an improved index
> for gps_points - probably something quadtile based, and maybe moving
> it to InnoDB to avoid the lock contention problems.
> > They're not joined to anything apart from the users table (are they?),
> > and the latter is sufficiently rarely updated that replication of some
> > sort would be feasible with minimal overhead.
> Aside from your code very little joining is done so there should be no
> problem having users in a separate database.
> Tom
> --
> Tom Hughes (tom at compton.nu)
> http://www.compton.nu/
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070904/214bf82e/attachment.html>

More information about the dev mailing list