Set :total_entries < 0 for uncounted paging. #250

Open
wants to merge 2 commits into
from

Conversation

Projects
None yet
7 participants
@HurricaneJames

Pagination on really large data sets is very slow because of the count(*) requirement to find number of pages. This can be fixed by setting :total_entries to the correct size. However, if you do not know what that is supposed to be you are stuck approximating.

This patch makes it possible to have just previous/next links whenever there are pages behind/ahead by setting :total_entries to -1. I figure -1 is a pretty good value for "I have no idea how many there are, but I DON'T want you counting either!"

There is one caveat with this method. The last page may be blank if the next to last page has the last item and is full.

@mislav

This comment has been minimized.

Show comment Hide comment
@mislav

mislav Jan 10, 2013

Owner

This is similar to #127. I'm thinking of supporting something like this. Counts suck sometimes

Owner

mislav commented Jan 10, 2013

This is similar to #127. I'm thinking of supporting something like this. Counts suck sometimes

@joevandyk

This comment has been minimized.

Show comment Hide comment
@joevandyk

joevandyk Apr 23, 2013

One way to fix the "last page being blank" issue is to fetch one more item than will actually be on the page. So if you are showing 10 per page, fetch 11. Then you can see if there's another page to display.

One way to fix the "last page being blank" issue is to fetch one more item than will actually be on the page. So if you are showing 10 per page, fetch 11. Then you can see if there's another page to display.

@joevandyk

This comment has been minimized.

Show comment Hide comment
@joevandyk

joevandyk Apr 23, 2013

@mislav what do you think needs to happen to support this properly?

@mislav what do you think needs to happen to support this properly?

@mislav

This comment has been minimized.

Show comment Hide comment
@mislav

mislav Apr 30, 2013

Owner

@joevandyk I don't like any of the implementations so far. They make the current arithmetic more convoluted, add no tests and seem poorly thought of.

An ideal solution would have a simple implementation and tests.

Owner

mislav commented Apr 30, 2013

@joevandyk I don't like any of the implementations so far. They make the current arithmetic more convoluted, add no tests and seem poorly thought of.

An ideal solution would have a simple implementation and tests.

@cmer

This comment has been minimized.

Show comment Hide comment
@cmer

cmer Aug 27, 2013

Count complete kills the performance of our database. The count alone takes 10 seconds on a complex SQL. We need a better way to just skip the count.

cmer commented Aug 27, 2013

Count complete kills the performance of our database. The count alone takes 10 seconds on a complex SQL. We need a better way to just skip the count.

@bcarpenter

This comment has been minimized.

Show comment Hide comment
@bcarpenter

bcarpenter Aug 14, 2014

+1 This would be great as well. On many of our actions, the count query takes as long as the actual query for an action that usually only yields 1 page of items. If we could return a single page and skip the count, that would be a 100% performance improvement.

This can be done manually, but it would be great if will_paginate supported this out of the box!

+1 This would be great as well. On many of our actions, the count query takes as long as the actual query for an action that usually only yields 1 page of items. If we could return a single page and skip the count, that would be a 100% performance improvement.

This can be done manually, but it would be great if will_paginate supported this out of the box!

@lonny

This comment has been minimized.

Show comment Hide comment
@lonny

lonny Aug 21, 2014

Depending on what database engine you are using, simply supplying a field to count can make a huge difference.

A few years ago, on one database with many millions of records (admittedly it was a slow machine but that amplifies the difference), count(*) took several MINUTES to complete, yet count(id) returned almost immediately.

I would suggest using something like count(id) as a default, and make using other columns an option. It should always be an indexed column with no nulls. The primary key is the obvious choice here.

If somebody wants to use count() they can, but making the worst case (i.e., count()) the default is not the best idea, in my opinion.

lonny commented Aug 21, 2014

Depending on what database engine you are using, simply supplying a field to count can make a huge difference.

A few years ago, on one database with many millions of records (admittedly it was a slow machine but that amplifies the difference), count(*) took several MINUTES to complete, yet count(id) returned almost immediately.

I would suggest using something like count(id) as a default, and make using other columns an option. It should always be an indexed column with no nulls. The primary key is the obvious choice here.

If somebody wants to use count() they can, but making the worst case (i.e., count()) the default is not the best idea, in my opinion.

@Galathius

This comment has been minimized.

Show comment Hide comment
@Galathius

Galathius Aug 1, 2016

👍

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment