On Nov 3, 2011, at 10:15 PM, Steve Teale wrote: > > I also have a question. MySQL potentially produces result sets of up to > 64 bit size - rows. The MySQL client theoretically copes with these by > storing a result set as a doubly linked list, and there's nothing to stop > me doing the same. But is it necessary? > > The whole point of a database seems to me to be to access the data you > need, rather than all the data in the Universe at the same time. Even if > I opt for result sets limited to 32 bit row numbers, if you pulled one > from the server with rows of only 20 bytes, you'd still be talking about > 80Gb of memory. Does any application do that sort of thing.
I think they probably did this simply to avoid imposing an artificial limitation on the number of rows that may be returned, regardless of whether anyone would actually do so. Practically speaking… an app designed to move the entire contents of a table from one DB to another might do this, though it would be far from the most efficient means of doing so. I can't think of any realistic example of an app that would want more than 2^32 rows in a response.
