Topic: Pagination Scalability Revisited

I saw a few posts on the forum talking about pagination scalability concerns when it comes to tables with millions of records, especially in response to the article by Kevin Clark on "Things You Shouldn't Be Doing in Rails". A few people commented Kevin's article was vague about specifics and I agree. So, I would like to reopen this topic up for discussion. If anyone here has specific code examples to illustrate the scalability issues, please feel free to share. If the current paginator code is so bad, instead of moving it into a plugin, maybe someone could write a better one and more importantly explain why the new version is scalable.

JiggyMe
"Videos that Matter to You" powered by Ruby on Rails

Re: Pagination Scalability Revisited

From my understanding, the primary scalability issue with the built in pagination is that it creates a separate object for each page. So when you're talking thousands of pages it will cause some unecessary performance problems. The majority of the Rails apps probably won't run into this so I don't really see it as that big of a deal. Someone please correct me if I'm wrong.

My biggest problem with pagination is not with the performance but with flexibility. I prefer to move my finds into the model (especially if it's complex) and the built in pagination makes this difficult. See my rant on this for an idea on how to fix it.

Railscasts - Free Ruby on Rails Screencasts

Re: Pagination Scalability Revisited

I haven't tried this one out yet, but his take on pagination seems spot on

http://errtheblog.com/post/929

Re: Pagination Scalability Revisited

There's a blog entry here about moving pagination into the model but the implementation looked a little strange to me...

implement-pagination-in-your-models

That said from what I read the pagination performance issues are like Ryan said restricted to high-traffic sites and the ones that use the more "advanced features" of the standard paginator, like the step thing.

I use paginator-1.0.0 myself. I don't know if it's any more efficient than the standard one but much more straightforward to use imho.