I have, after further googling, discovered that the 4.2 billion figure that MySQL uses as 'max_rows' is, indeed, max_rows and not a max database size in bytes. In theory I have solved my problem, and wasted however many peoples bandwidth by putting all these eMails to the MySQL list.
Mea culpa, mea culpa, mea maxima culpa. I slink to my corner with Google in hand and apologise for wasting your time. Here's hoping, of course, in four days I don't find out I'm wrong about the 4.2b rows part. - JP On Thu, 22 Mar 2007, JP Hindin wrote: > Addendum; > > On Thu, 22 Mar 2007, JP Hindin wrote: > > Zero improvement. I used the following CREATE: > > MAX_ROWS=1000000000; > > At first I thought I had spotted the obvious in the above - the MAX_ROWS I > used is smaller than the Max_data_length that resulted, presumably MySQL > being smarter than I am. So I changed the MAX_ROWS to use larger numbers, > ala: > AVG_ROW_LENGTH=224, > MAX_ROWS=200000000000; > > But after creation the 'SHOW STATUS' gives the following: > > Create_options: max_rows=4294967295 avg_row_length=224 > > My guess is that MySQL has decided 4294967295 is the maximum table size > and ALTERs nor CREATE options are able to change this imposed limit. This > would explain why my ALTERs didn't appear to work, seg fault of the client > aside. > > So I suppose the question now is - if MAX_ROWS doesn't increase the table > size, what will? Where is the limit that MySQL is imposing coming from? > > Again, many thanks for anyone who can enlighten me as to what MySQL is > thinking. > > JP > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
