Hello Sergei, Gunnar, and others, thank you for your quick responses. One little mystery remains:
Why does one need to read all the row data (with SQL_CALC_FOUND_ROWS) to get the total number of results when using a limit? When the index is used to find relevant rows and sort the results, the code certainly must know how many total results there are. Could one not store the total while using the index and use "select FOUND_ROWS()" without SQL_CALC_FOUND_ROWS to retrieve the total? Thanks and regards, TK --- Sergei Golubchik <[EMAIL PROTECTED]> wrote: > Hi! > > On Dec 04, tk wrote: > > Hello, > > > > Thanks for the response. > > There is one thing that is not clear however. > > > > Regardless of whether or not I perform the > fulltext > > search with or without the SQL_CALC_FOUND_ROWS > > keyword, the results that I get are exactly the > same. > > > > Also, the notion of stopping after the limit is > > reached cannot apply in the fulltext search or > > otherwise we would only get the first 10 matches > but > > not the first 10 "most relevant" matches. This > leads > > me to believe that the fulltext search must be > looking > > at all the rows in both cases since it otherwise > would > > not find the same first 10 most relevant records. > > Hence the question why there should be a > difference in > > time. > > The difference is that you only need to read 10 rows > from the disk > without SQL_CALC_FOUND_ROWS. > > With SQL_CALC_FOUND_ROWS MySQL goes on and reads all > rows, it takes > time. > > Finding relevant rows and sorting is based on index > only, row data are > not read. > > Regards, > Sergei __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
