Using offset is not a good solution for a lot of cases, it will have to scan over offset entities which is slow. My comment is in regard to queries / fetches. Running a query is the same with 10 or 1,000 or 100,000,000 rows; performance will be related to the number of rows you are trying to fetch.
Unfortunately cursors are a one-way-street right now, but they make it simple to implement "next" type functionality. However, you can store the "previous" cursor positions so that you can nicely implement previous. You can also store 'key' points in the cursor (such as every 100 entities), then scan forward from that point. Then if a user goes way down the line and "suddenly jumps back" you can find a close cursor without having to store _every_ cursor. There are a few existing solutions that you can use for this (just google app engine cursors paging). Querying on a timestamp is fine. Robert On Wed, Feb 23, 2011 at 04:59, tobik <tobiaspoto...@gmail.com> wrote: > Independent? Now I'm confused. Does it or does it not matter whether I > select first page or 100th using offset? > > I checked the cursors, it looks nice, but it seems to me, that it's > good only for "next next next" type of pagination. If the user jumped > from the first to the 100th page and then back to the 50th page, I > would still need to go through all previous entries and it would be > slow. Or am I wrong? Naturally, I know that "next next" type of > pagination would be suitable for most of cases. > > Ok and really last question, I hope I don't bother you much. What > about pagination based on time periods. For example like "all entries > created today, yesterday, last week, last month". It would use simple > filtering (greater than, less than) so it should be fast.. or not? > > > On 23 ún, 06:25, Robert Kluin <robert.kl...@gmail.com> wrote: >> Performance is independent of the number of entities you have. >> Namespaces are great for segregating data, but you can't query across >> them -- you'll only get results from one. >> >> Like Chris mentioned, use cursors instead of offsets. And if you can, >> then yes a well thought out caching strategy is a good way to improve >> performance. >> >> Robert >> >> On Tue, Feb 22, 2011 at 18:57, tobik <tobiaspoto...@gmail.com> wrote: >> > Sorry, one more tricky question. What about namespaces. If I had 10 >> > namespaces and in each namespace 10 entries, would the performance be >> > the same as if I had only one namespace but with 100 entries? >> >> > On 22 ún, 23:31, Chris Copeland <ch...@cope360.com> wrote: >> >> Django's Paginator is not going to be efficient on GAE and is definitely >> >> not >> >> going to scale. >> >> >> GAE provides cursors which are a very efficient way to page through query >> >> results:http://code.google.com/appengine/docs/python/datastore/queries.html#Q... >> >> >> On Tue, Feb 22, 2011 at 3:57 PM, tobik <tobiaspoto...@gmail.com> wrote: >> >> > I built a page using Django's Paginator which displays a simple table >> >> > with 20 items from around 1000 total stored in database. I don't know >> >> > how the Paginator works from the inside, but according to the >> >> > appstats, it makes two queries (first counts items, second selects >> >> > given page) and each one of them takes around 130ms of cpu time. Is it >> >> > a normal value? The truth is that the page loads noticeably slower >> >> > than a page without any queries. And I also counted, that with 6.5 cpu >> >> > hours limit I can afford around 3000 such queries every day which is a >> >> > quite small number. And it's only 1000 entries in the database. >> >> >> > So far I've been using PHP+MySQL and I am used to that such simple >> >> > queries are really fast, even on poor free hostings. I tried to apply >> >> > caching on every single page generated by Paginator and it naturally >> >> > reduced the loading time to minimum. So is it the right approach to >> >> > AppEngine? Cache everything as much as possible? >> >> >> > -- >> >> > 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. >> >> > -- >> > 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 >> > athttp://groups.google.com/group/google-appengine?hl=en. >> >> > > -- > 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. > > -- 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.
