[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