Good thing I didn't rewrite my code before asking :-). I see the asynctools Jason posted, but I would be looking for a join (in the thread sense) that allows continued processing once all the results are back.
On Fri, Sep 4, 2009 at 8:44 AM, Nick Johnson (Google)<nick.john...@google.com> wrote: > Hi Jeff, > IN queries are split up into multiple basic queries entirely in user code, > so there's no latency or other benefit to using them over doing multiple > queries yourself - it's just for convenience. In future, though, the > MultiQuery interface may be extended to do its queries in parallel. > -Nick > > On Fri, Sep 4, 2009 at 4:30 PM, Jeff Enderwick <jeff.enderw...@gmail.com> > wrote: >> >> I read somewhere that IN queries are processed serially by the >> datastore. GOOGers, what is a rough rule-of-thumb on the benefit of >> using IN? For example, if the base RT latency for anything with the >> datastore is Nms, then could guesstimate that using N for a list of 3 >> is not a huge latency win, but using IN for 10 is. Does using IN >> substantially cut down on the api_cpu_ms used vs sequential queries? >> >> > > > > -- > Nick Johnson, Developer Programs Engineer, App Engine > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
