# Recommendations on pagination? **URL:** \ **Category:** Rails\ **Created:** [August 30, 2006, 8:01pm UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987 "2006-08-30T20:01:52Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 30, 2006, 8:01pm UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/1 "2006-08-30T20:01:52Z")
So, I just finished reading Kevin C.'s excellent article at: [http://glu.ttono.us/articles/2006/08/30/guide-things-you-shouldnt-be-doing-in-rails](http://glu.ttono.us/articles/2006/08/30/guide-things-you-shouldnt-be-doing-in-rails) I was feeling pretty smug with myself (although I did have a Find\_All to get rid of) until I got to the pagination part. Its great information about its performance problems, but I’m not sure what to do now. I did find paginate\_by\_sql, which seems like a good approach to me: [http://thebogles.com/blog/2006/06/paginate\_by\_sql-for-rails-a-more-general-approach/](http://thebogles.com/blog/2006/06/paginate_by_sql-for-rails-a-more-general-approach/) What is the best practice in this area? ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 30, 2006, 10:04pm UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/2 "2006-08-30T22:04:06Z")
If it works and your data set is small enough that it’s happy and quick, then stick with it. If you’re having speed problems, then think about writing something custom. Definitely don’t just rewrite something because that’s what all the cool kids are doing! 🙂 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 30, 2006, 10:51pm UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/3 "2006-08-30T22:51:08Z")
I’m with Tom. Until I actually start seeing a performance impact. I currently have tens of thousands of rows, not millions. Joe ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 31, 2006, 12:36am UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/4 "2006-08-31T00:36:28Z")
“Joe R.” wrote: > I’m with Tom. Until I actually start seeing a performance impact. I > currently have tens of thousands of rows, not millions. If I recall, the documentation says to perform SQL row count instead of fetching rows when getting the items\_count. I wonder if people used this approach and still seeing performance issues with large row set. Should I be concerned…? Long ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 31, 2006, 12:52am UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/5 "2006-08-31T00:52:30Z")
Can anyone confirm the behavior of ac.save? I mean what happens when a model is retrieved and a subset attributes are modified and then saved? I have the impression every field in the row is updated regardless, even if the field had not changed. This seems not efficient and can cause a dirty-write in some situations. Does ac.save support field-specific updates? If so how… Thanks, Long ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 31, 2006, 1:08am UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/6 "2006-08-31T01:08:33Z")
On Wed, 2006-08-30 at 19:54 +0000, Tom T. wrote: > If it works and your data set is small enough that it’s happy and > quick, then stick with it. If you’re having speed problems, then think > about writing something custom. > > Definitely don’t just rewrite something because that’s what all the > cool kids are doing! 🙂 * * * I’m looking at scaling issues from the width dimension rather than the depth dimension. I have a table that has 143 columns which are split amongst 7 data input screens and I am thinking that it would be faster/less memory intensive to only retrieve the specific fields necessary for each particular input screen and of course, the list view. Does anyone do this? Craig ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 31, 2006, 1:12am UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/7 "2006-08-31T01:12:34Z")
On 8/30/06, Long [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Can anyone confirm the behavior of ac.save? I mean what happens when a > model is retrieved and a subset attributes are modified and then saved? > > I have the impression every field in the row is updated regardless, even > if the field had not changed. This seems not efficient and can cause a > dirty-write in some situations. > > Does ac.save support field-specific updates? If so how… The entire record is always saved. Add a lock\_version column to enable optimistic locking. jeremy ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 31, 2006, 2:56am UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/8 "2006-08-31T02:56:41Z")
Long wrote the following on 31.08.2006 00:39 : > Can anyone confirm the behavior of ac.save? I mean what happens when a > model is retrieved and a subset attributes are modified and then saved? > > I have the impression every field in the row is updated regardless, even > if the field had not changed. This seems not efficient and can cause a > dirty-write in some situations. > > Does ac.save support field-specific updates? If so how… You’ll break validation… You could override update\_attribute (which doesn’t do validation anyway). Lionel. ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [August 31, 2006, 12:58am UTC](https://www.ruby-forum.com/t/recommendations-on-pagination/66987/9 "2006-08-31T00:58:54Z")
Long wrote: > “Joe R.” wrote: > > > I’m with Tom. Until I actually start seeing a performance impact. I > > currently have tens of thousands of rows, not millions. > > If I recall, the documentation says to perform SQL row count instead > of fetching rows when getting the items\_count. I wonder if people used > this approach and still seeing performance issues with large row set. > > Should I be concerned…? > > Long Getting a count of ALL rows shouldn’t be expensive - mysql caches it, and I think PostgreSQL also started caching it. Counts WITH condition clauses can be expensive if there are a lot of rows. Joe