I disagree. The 4GB slowdown is usualy caused by indexing problems associated with the OS having increased overhead when looking up and inserting data. I have eliminated this slowdown in Solaris and Linux be re-indexing the entire database once it becomes larger then 4GB. This fixes the problem from what I could tell.
I would also like to note that if there was a pointer issue when switching to 64 bit pointers, it would only effect perfomance on computer with less then sufficent amounts of processing power to calculate the larger pointers. Benjamin Arai [EMAIL PROTECTED] On Fri, 11 Jan 2002, James Montebello wrote: > > This is speculation: > > They're slower because many operations have to be done using 64 bit > values rather than 32 bit values. You set the flag by setting the max > data size when creating the table. You can also alter this after the > table is created with ALTER TABLE. The doc suggests you're setting the > actual maximum size, but if you set the size to even 1 byte past 4GB > (at least on Solaris), it immediately flips to a value way above 4GB, > which is probably the Solaris limit (may be 2TB, I forget). Not sure > what it does on Linux. > > We saw a significant performance decrease on Solaris when we tried to > use max table sizes above 4GB, and assume it's because of an internal > switch from 32-bit pointers to 64-bit pointers. May not make nearly as > much of a performance difference on a real 64-bit processor and OS. > > james montebello > > On Fri, 11 Jan 2002, Aaron Brick wrote: > > > > Yes and no. With 3.23, the MyISAM format will, by default, have a 4GB > > > limit (32 bits). You can set flags on the table to allow a 64-bit table, > > > and you'll generally hit an OS or physical limitation long before you > > > run out of space. The downside of the 64-bit version is it's considerably > > > slower. Better to split large datasets up into sub-4GB units. > > > > why are operations on the >4GB tables slower? > > > > and, incidentally, where is that flag set? > > > > thanks, > > > > aaron brick. > > > > > > ________________________________________________ > > / \ > > | Aaron Brick (415) 206 - 4685 | > > | [EMAIL PROTECTED] Room 3501C, SFGH | > > > > Programmer Analyst, Functional Genomics Core > > Sandler Center for Basic Research in Asthma > > Lung Biology Center, Department of Medicine > > San Francisco General Hospital > > University of California, San Francisco > > > > --------------------------------------------------------------------- > > Before posting, please check: > > http://www.mysql.com/manual.php (the manual) > > http://lists.mysql.com/ (the list archive) > > > > To request this thread, e-mail <[EMAIL PROTECTED]> > > To unsubscribe, e-mail <[EMAIL PROTECTED]> > > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > > > > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
