On Feb 8, 1:33 pm, Stephen <[email protected]> wrote: > What are the performance characteristics of cursors?
good question! we'll address this in the docs, but for now... > 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. that offset field is very rarely used, only e.g. if you provide an offset on the original query, start it but don't actually fetch any results, then ask for the cursor. cursors store direct pointer(s) to the index row(s) where the query will resume scanning. in that sense, they work the same way as the existing bookmark techniques, except they're (obviously) much easier to use, work with any query, and don't require any extra property(ies). > 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? no, cursors are stateless. all necessary information is included in the cursor blob itself. among other things, this happily means that resuming a cursor years later is just as fast as resuming it seconds later. -- 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.
