On Feb 11, 11:31 am, Waldemar Kornewald <wkornew...@gmail.com> wrote: > > Will every query that works directly on a (composite) datastore index > be almost as fast as db.get()?
as a general rule, no. queries that scan indices will always have to do at least two serial disk seeks, one to read the index and one to look up the entities the index rows point to. gets only need a single disk seek, since they have the entities' primary key. having said that, one vs two disk seeks isn't always the dominating factor for latency. instead, python protocol buffer decoding might dominate, or the bigtable tablet server RPCs might, e.g. if you're fetching many entities from many different tablet servers. (we'll issue a lot of RPCs in parallel on your behalf, but not arbitrarily many.) note that this only applies to queries that use an index. kindless ancestor queries and queries on __key__, for example, scan the entities table directly, so they'll only need a single disk seek. > Why don't you also increase the number of retries for > run_in_transaction? agreed, we probably will, hopefully as soon as 1.3.2. -- 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-appeng...@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.
