I got beaten to this answer. No, there is no traversal to get to the offset.
BigTable has an underlying mechanism for range queries on keys. Indexes are essentially a key comprised of a concatenation of application ID, entity type, column, value. When a filter operation is performed, the datastore looks for a range matching this criteria, returning the set of keys. A cursor also adds the datastore key of the entity so it is possible to serialize where to begin the query. This is actually a bit awkward to explain without visuals. You can watch Ryan Barrett's talk here: http://www.youtube.com/watch?v=tx5gdoNpcZM Hopefully, we'll be able to post an article at some point in the future explaining how cursors work. 2010/2/8 Alkis Evlogimenos ('Αλκης Ευλογημένος) <[email protected]> > There is no offset. The protocol buffer stores a start_key and a boolean > denoting if this start key is inclusive or not. The performance of > continuing the fetch from a cursor should be the same as the performance of > the first entities you got from a query. > > On Mon, Feb 8, 2010 at 4:33 PM, Stephen <[email protected]> wrote: > >> >> >> On Feb 8, 7:06 pm, "Ikai L (Google)" <[email protected]> wrote: >> > The official docs are pending, but here's Nick Johnson to the rescue: >> > >> > http://blog.notdot.net/2010/02/New-features-in-1-3-1-prerelease-Cursors >> >> >> What are the performance characteristics of cursors? >> >> The serialised cursor shows that it stores an offset. Does that mean >> that if the offset is one million, one million rows will have to be >> skipped before the next 10 are returned? This will be faster than >> doing it in your app, but not as quick as the existing bookmark >> techniques which use the primary key index. >> >> Or is the server-side stateful, like a typical SQL implementation of >> cursors? In which case, are there any limits to the number of active >> cursors? Or what if a cursor is resumed some time in the future; will >> it work at all, or work slower? >> >> -- >> 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]<google-appengine%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> >> > > > -- > > Alkis > > -- > 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]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- Ikai Lan Developer Programs Engineer, Google App Engine http://googleappengine.blogspot.com | http://twitter.com/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.
