[wp-trac] [WordPress Trac] #29552: Slight tweak to no_found_rows logic in WP_Query
WordPress Trac
noreply at wordpress.org
Mon Oct 13 19:32:20 UTC 2014
#29552: Slight tweak to no_found_rows logic in WP_Query
-------------------------------+------------------------------
Reporter: dmchale | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Query | Version: trunk
Severity: normal | Resolution:
Keywords: reporter-feedback | Focuses: performance
-------------------------------+------------------------------
Changes (by boonebgorges):
* keywords: => reporter-feedback
Comment:
Thanks for the patch, dmchale.
> 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)
I can't reproduce this. Check out the last two tests in
[attachment:29552.tests.patch]. They declare `nopaging=true` and
`posts_per_page=-1`, and in each case, you can see that the request query
does *not* contain `SQL_CALC_FOUND_ROWS`. When you have `LIMIT` clauses,
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 how `found_posts` is set in
these cases.
Can you say more about your "edge cases"?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29552#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list