* Chris <dmagick@xxxxxxxxx> [061211 07:01]: > select SQL_CALC_FOUND_ROWS userid, username, password from users limit 10; > > will do: > > select userid, username, password from users limit 10; > > and calculate this: > > select userid, username, password from users; > > and tell you how many rows that will return (so you can call 'found_rows()'). > > > the second one does do a lot more because it has to send the results across to the client program - whether the client uses that info or not doesn't matter. Not really. Sending the data to the client is usually (if you are not connected via some small-bandwidth connection) a trivial cost compared to calculating the number of rows. (Our tables involve 100Ms of rows, while the net connectivity is a private internal Gigabit net, returning the data seems never to be an issue. Reading it from the disc, selecting the rows are issues. Not sending the data.) Actually, if you think that sending the data is an issue, PG offers the more generic concept of cursors. Andreas
