![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 12 years ago
Closed 10 years ago
#29552 closed enhancement (worksforme)
Slight tweak to no_found_rows logic in WP_Query
| Reported by: | dmchale | Owned by: | boonebgorges |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Query | Version: | 1.5 |
| Severity: | normal | Keywords: | reporter-feedback needs-testing has-patch |
| Cc: | Focuses: | performance |
Description (last modified by )
It seems that edge cases could introduce times when a query WOULD have limits but NOT want them (when the query was passed nopaging=true or post_per_page=-1). When this happened, SQL_CALC_FOUND_ROWS would be invoked in the query and hinder performance of the query.
Code change still allows for a developer to override no_found_rows with their own value, but now checks the nopaging and post_per_page variables to possibly set no_found_rows to true anyway. By using one of those 2 variables to ask for EVERYTHING, we know the developer does not want/need pagination. This forces the issue so that by the time we get to the line...
if ( !$q['no_found_rows'] && !empty($limits) )
...we don't find ourselves WITH limits, and a False value for no_found_rows, in spite of the fact that the developer had asked for "all".
Thanks for the patch, dmchale.
I can't reproduce this. Check out the last two tests in 29552.tests.patch. They declare
nopaging=trueandposts_per_page=-1, and in each case, you can see that the request query does *not* containSQL_CALC_FOUND_ROWS. When you haveLIMITclauses, WP_Query does not append the SQL_CALC_FOUND_ROWS keyword. See https://core.trac.wordpress.org/browser/tags/4.0/src/wp-includes/query.php?annotate=blame#L3376. See also https://core.trac.wordpress.org/browser/tags/4.0/src/wp-includes/query.php?annotate=blame#L3611 to see howfound_postsis set in these cases.Can you say more about your "edge cases"?