On 09/12/09 20:27, Peter Körner wrote:
Such an api could create heavy load on the underlying
database, what is
AFAIR the main reason why such calls aren't implemented in the current
api. But unlike on the main api, queries to an such a history api don't
need to be answered in miliseconds. When a /map query for a city on 1st
jan 2007 takes 15 minutes, well that's ok. I's still faster than to
download the corresponding planet dump, import int into postgis and
catch up with the diffs, so what?
You may not mind that it takes 15 minutes to answer your query but the
problem is that long query times like that probably won't scale because
if an average query takes 15 minutes then the server (assuming that
we're talking an I/O bound process) can only handle four queries per
hour before it starts running into the ground.
Even if it's CPU bound you'll only manage 4 queries/CPU/hour.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://www.compton.nu/