[wp-trac] [WordPress Trac] #29552: Slight tweak to no_found_rows logic in WP_Query

[WordPress Trac]

#29552: Slight tweak to no_found_rows logic in WP_Query
---------------------------------------------+-----------------------------
 Reporter:  dmchale                          |       Owner:
     Type:  enhancement                      |      Status:  new
 Priority:  normal                           |   Milestone:  Awaiting
Component:  Query                            |  Review
 Severity:  normal                           |     Version:  1.5
 Keywords:  reporter-feedback needs-testing  |  Resolution:
                                             |     Focuses:  performance
---------------------------------------------+-----------------------------
Changes (by johnbillion):

 * keywords:  reporter-feedback => reporter-feedback needs-testing
 * version:  trunk => 1.5


Old description:

> 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".

New description:

 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".

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29552#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform