Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.When using pager_query, we don't need a seperate query to ask the database for the number of rows, if we run the main query itself first and it returns less than $limit. This will happen on the last page of a paginated query (which probably happens a bit more often than you expect)
Example (user search):
20.31 1 pager_query SELECT COUNT(*) FROM users WHERE LOWER(name) LIKE LOWER('%ab%')
0.67 1 pager_query SELECT name, uid FROM users WHERE LOWER(name) LIKE LOWER('%ab%') LIMIT 0, 15
See attached patch - applies to both 5.1 and HEAD
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | page-optimization_1.patch | 1.58 KB | lyricnz |
| #1 | page-optimization_0.patch | 1.57 KB | lyricnz |
| page-optimization.patch | 1.6 KB | lyricnz |
Comments
Comment #1
lyricnz commentedUpdate - remove debugging code - sorry.
Comment #2
lyricnz commentedUpdate - coding style
Comment #3
lyricnz commentedComment #4
lyricnz commentedAssigning to 6.x-dev
Comment #5
david straussI haven't tested it, but the code looks good to me. I'm not sure I buy the benchmark of the current code, but this change could only make things faster.
Comment #6
lyricnz commentedYeah, the query cache is likely to make the second query pretty fast, no matter which order they're in - but the less queries the better.
Comment #7
catchThis still applies but I'm not sure how to test it. Seems like it could be a decent performance boost though.
Comment #8
catchfatal error on admin/content/node
Comment #9
lyricnz commentedNow that db_num_rows() has been removed, I don't think this optimization is possible - we don't fetch each of the rows in the query here, so we no longer know how many rows are returned.