Peter Körner wrote: >> I think the problem is that the current setup is too slow to render low >> zooms, with single metatiles taking partly over a minute to render. This >> is therefore clearly not feasible to render on the fly. However, with >> the 200+ styles of cassini, the fraction of low zoom tiles to high zoom >> tiles is skewed in the wrong direction. Once you get down to zoom level >> 12 or so, it starts just about being fast enough to render on the fly. > > Maybe adding an index on place and capital would help already.. > How are the indexes on the main osm tile server?
After a chat with a couple of people on the osm-irc yesterday, it seems like the following. The indexes on the main site are only those that osm2pgsql creates, which are indexes on the geometry columns for all of the tables, but none of the other columns. The two SQL calls that are done on layers 2 - 4 are the search for places and admin boundaries. Doing those queries with a simple count of results without returning results only takes about 2 - 4 seconds on either cassini or the osm tile server. So an index could save some time, but not particularly much, at least not compared to the overall time of tens of seconds to a minute it seems to take to render a metatile. However, the simple count / lookup might not be the problem, but returning the results may. At some point apparently, those calls returned results in excess of 1Gb of data, although I don't know if that is still the case or some recent optimisations have helped there. So there has been some thought about splitting out the admin boundaries into separate tables for the low zoom and running line simplification algorithms on those to reduce the data volumn, as the full accuracy isn't really needed on low zoom tiles. But it is probably worth checking out which queries do actually take all the time and Frederik Ramm has written some scripts to analyse the postgres log files to check where the time is actually spent in rendering. This requires to enable the statement and duration logging features of postgres, which might be worth enabling for a while to see where the bottleneck is. Kai > > Peter > > _______________________________________________ > Maps-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/maps-l _______________________________________________ Maps-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/maps-l
