Paul DuBois writes: > At 17:26 -0700 10/6/03, Don Cohen wrote: > >http://www.mysql.com/documentation/mysql/bychapter/manual_Clients.html > >says > > > > you must retrieve all the rows even if you determine in > > mid-retrieval that you've found the information you were looking > > for. > > > >My question is: why? > > Because there is no provision in the client/server protocol > whereby the client can interrupt a transfer from the server that > has started.
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 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? > >In fact I thought that the normal interface for a database would show > >a screen full of results and then let you decide whether to go on to > >the next screen or quit. It seems crazy that if you do a query that > >gives a million results you have to retrieve them all. > > If you're really making the server do all the work of retrieving > a million rows, especially for an interactive program, you might > consider rewriting the query. For example, with LIMIT. > > Anyway, if you call mysql_free_result(), it will take care of > retrieving and discarding and unfetched rows. The whole point here is that I *DON'T* want the server to generate all those rows. But I don't necessarily know how many I'll need at the beginning. Perhaps in some cases it will be necessary to generate all the rows in order to return the first one (for instance, if I ask for them to be sorted), but for the queries I intend to use I'd hope it would be possible to generate n tuples in time o(n). -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
