[OSM-dev] Too many slow queries in db
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 Hughes (tom at compton.nu)
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev