It is not correct to say that 'the range-scan / order on must go last'. If the requested range-scan/sort-order is on the same property as the primary sort then there is no work for appengine to do. The results simply fall out in the required order.
A dilettante such as myself expects a performance-optimised system to suggest indexes sorted in such a way that they can take advantage of this, but appengine did not do so. It suggested the same index regardless of what sort order my query requested. This suggests to me that appengine is either very highly performance-optimised in this area, or is not performance-optimised at all. >From reading the BigTable paper (bigtable-osdi06.pdf) I see that BigTable files are found by traversing a B+ tree with a maximum of 3 levels. If a web search query is handled by taking the intersection of n single-property index scans all of which go through these B+ trees, then that's good performance optimisation. I assume that this is how google does web search. But composite indexes force you to work linearly. You can't parallelise. My guess is that an un-optimised composite index is significantly inferior to parallel single-property index scans. So I can refine my question a little: how does appengine traverse its * composite* indexes when performing a query ? -- 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.
