[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