A view can be set up to limit the number of items per page, but not show any pagers for accessing possible hidden items (other pages). With such a setup, view#execute still runs the $count_query to check the total number of matching items, although there is no use for that information since no pager will be displayed.
I therefore suggest moving the code that runs the query to set $this->total_rows so that it is run only when needed. Skipping one query should improve the performance a bit.
The $this->total_rows variable does not seem to be used anywhere else in the modules that I use. Since it is saved into the View-object there is a risk that some other module relies on it, but I consider it a private attribute, since there is no getter for it. Perhaps one should also turn $this->total_rows into a local $total_rows, to enforce that those interrested should use $pager_total_items[$this->pager['element']] instead.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | views_no_count_without_pager.diff | 1.48 KB | emok |
Comments
Comment #1
emok commentedThe patch:
Comment #2
merlinofchaos commentedI put that in on the grounds that the number of total rows has been a requested feature, though without the pager it does seem much less useful. Will need to think on this a bit.
Comment #3
moshe weitzman commentedThis is really bad when you have 100K nodes, since just counting them has brutul performance when you have any JOINS.
Comment #4
moshe weitzman commentedActually, it would be fantastic if the mini pager did not do a count query either. It doesn't actually need to know the number of items in the View. The only gotcha is that it has no way of knowing that there really is an 11th in a 10 per page rendering. thats unfortunate, but the COUNT() query is even more unfortunate for large datasets with joins (I am staring at 15 seconds right now). I think the minipager can always just select out 11 items in that case and discard the last. the 11th only exists as a signal that a next page is needed.
I'll work some more on this patch if I can get some input from merlin about its usefulness and how to incorporate my minipager thoughts.
Comment #5
moshe weitzman commented@Earl - any thoughts on the minipager idea?
Comment #6
merlinofchaos commentedSorry, I thought I responded.
Since the mini pager says "page 1 of X" I don't see how not counting will work.
Comment #7
moshe weitzman commentedWhat about dropping the 'of x'. How much value does that really add?
Comment #8
moshe weitzman commentedThe initial here has been fixed. A non pager query now skips the count query.
I leave this issue open as a request for a pager (maybe not minipager?) that also skips the count query but has prev/next
Comment #9
merlinofchaos commentedThis might be getting into the land of "make pluggable pager system". I had thought about doing that...and then didn't.
Don't we still need to do the count query to know if there's a next page, though?
Comment #10
moshe weitzman commentedThe query would select one more item than needed in order to know if a next should be shown. The View already knows if Previous should be shown. The extra item needs to then be discarded.
Comment #11
merlinofchaos commentedThis'll possibly be something that can happen after the pagers are pluggable. There is a patch: http://drupal.org/node/586668