Please reply to [EMAIL PROTECTED] (not to me personally), so that others can follow this thread.
At 18:55 -0700 10/6/03, Don Cohen wrote:
Paul DuBois writes:
> >Perhaps I misunderstood the doc but I thought by using _use_result > >I was asking for the server not to send the next tuple until I asked > > Correct, the server doesn't send the row until you ask for it, > but you cannot tell it, "don't send any more".
But before you wrote:
> Anyway, if you call mysql_free_result(), it will take care of > retrieving and discarding and unfetched rows.
If so, this does seem to be a way of telling the server you don't want any more results.
No. mysql_free_result() may keep you from having to do it yourself, but the rows must still be fetched. It's just that mysql_free_result() does it for you.
The real question is then whether the cost of reading n results out of m and then doing the free_result is really proportional to n or to m.
It's n+m in any case. All rows must be fetched.
> >for it. Otherwise what's all this stuff about using less space cause > >you only have to store one tuple at a time, and the stuff about not > >using this method if you might want to wait for a long time in the > >middle which would cause locking problems? > > I'm not sure how either of those factors are relevant to the question > at hand.
The first part (less space) would be relevant if the entire result were sent from the server and you just retrieved the rows incrementally from some buffer in the client. Even if the server internally generated the entire output at the beginning and stored them itself, but just delivered the rows incrementally as the client asked, then there would be no need to keep tables locked while there were undelivered tuples.
> You might want to use LIMIT in conjunction with SQL_CALC_FOUND_ROWS. I think this means that the query includes a limit. If so that requires that you know the limit before you see any results.
It includes a LIMIT, but there's more to the story. Check SQL_CALC_FOUND_ROWS (and FOUND_ROWS()) in the manual. This may not suit your purposes; then again, it may.
I want a way to look at the result and decide that's enough.
I believe I've already indicated that you cannot. A cancel may be implemented at some point, but I don't know when.
-- Paul DuBois, Senior Technical Writer Madison, Wisconsin, USA MySQL AB, www.mysql.com
Are you MySQL certified? http://www.mysql.com/certification/
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
