[wp-trac] [WordPress Trac] #10469: use of SQL_CALC_FOUND_ROWS needs to be eliminated

WordPress Trac wp-trac at lists.automattic.com
Thu Jul 23 11:48:08 UTC 2009


#10469: use of SQL_CALC_FOUND_ROWS needs to be eliminated
--------------------------+-------------------------------------------------
 Reporter:  _ck_          |       Owner:  ryan        
     Type:  defect (bug)  |      Status:  new         
 Priority:  normal        |   Milestone:  2.9         
Component:  Query         |     Version:  2.9         
 Severity:  normal        |    Keywords:  dev-feedback
--------------------------+-------------------------------------------------

Comment(by _ck_):

 Thanks for investigating further. Be sure to use realworld database sizes
 if possible of course.

 In theory you could have the best of both worlds, ie. keep the option for
 SQL_CALC_FOUND_ROWS in the core as a fallback and work around it using a
 separate COUNT() query when you know it will be faster. This is how
 bbPress 1.0 currently handles it, since SQL_CALC_FOUND_ROWS was folded
 back in it's core via backPress.

 I suspect this other idea is outside the realm of hope for a near-future
 improvement, but in theory the total query count should be stored per
 session, that way during pagination the more expensive total rows query is
 not repeated on every page load for that user.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10469#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list