In the meantime, you can use http://code.google.com/p/asynctools/ to kick off parallel queries.
It doesn't (yet) directly support MultiQuery, so you'll need to rewrite your IN queries as a set of equality queries. j On Sep 4, 9:44 am, "Nick Johnson (Google)" <[email protected]> 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 > <[email protected]>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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
