[OSM-dev] [OSM-talk] donating read-only api-mirrors

Matt Amos zerebubuth at gmail.com
Sat Feb 7 05:23:25 GMT 2009

On Sat, Feb 7, 2009 at 4:56 AM, Stefan de Konink <stefan at konink.de> wrote:
> Matt Amos wrote:
>> indeed, with this method either the node and way IDs are cached (i.e:
>> stored in memory) or the query is repeated (wasting time).
> Some databases cache their results or even complete queries when noting is
> modifies. Why would you like to outperform [insert database brand here] with
> futile [insert language here]?

my point was that the node IDs in the bbox are used twice (well,
actually three times for the relation members as well) and, whether
you use some database brand or futile language, they must either be
stored or recomputed. the storage may be cache or temporary tables in
the server or in custom code, but it is an unavoidable trade-off of
time and space.

>> i wouldn't count on it. mysql's query optimiser is frequently wrong.
> Frequently means that it can be right too; did someone test that subsets are
> cached within queries or not?

a simple test with (select sleep(1)) suggests not, but getting the
best performance out of mysql is somewhat of a black art.

> Now do this for any query method you want to bench and do something with
> gnuplot ;) And see which query gives you the best overal performance. If
> there are significant things to see in your output, you might partition your
> query type based on the parameters, in this case bbox.

have you put the results of this online anywhere? i would be
interested to see them.

>> currently all errors are indicated by HTTP status codes. i'm sure
>> you'd agree that sending back broken content != indicating an error.
>> in HTTP-based protocols its a good idea to be standards compliant and
>> use the error reporting mechanisms that all clients (including wget,
>> curl, etc...) will understand.
> Maybe the API is HTTP based, the XML output is certainly part of another
> language. I think that the amount of trouble streaming output saves hinting
> an error in XML is minor sacrifice, especially when you relate this to the
> final document validness and the chance it is suddenly hitting an error when
> there already is output.

i agree there is a balance between ideological standards-compliance
and practicality. :-)

this is something to discuss with tool authors if there is some
concrete evidence of the superiority of the streaming approach.



More information about the dev mailing list