Re: Whatcha' wanta have?????

Dave Griffen wrote: > Upon further review of your comments...It sounds like your looking for ways > to make the 4TB chunk be more useable but not to increase fragment size. > That brings to mind another question, how many fragments can a single table > have? From sifting through the manuals the answer seems to be 255 and your > comments lead me to think you don't have plans on changing that limit. Can you cite the reference(s) from which you deduce the 255 fragment limit. I don't think it is real, but I could be wrong. > So > if your not planning on increasing data pages per fragment or fragments per > table, we would still be left with the same Table Size Limit of 4TB? That is not the intention. > I understand the bit limit. For me, finding the 8-bit fragment id reference > seems to give a good explanation of why the fragments can only hold 24-bits > worth of pages. I also understand why these things didn't change in IDS > 9.4. And in addition to the reasons you mentioned it would seem likely that > support for 32-bit OS's would also be a factor. However, in looking forward > to future IDS versions, I would still like to see these numbers increased. > Even if that means a DBMS that only runs on 64-bit platforms and has a one > way migration path (in-place migration would still be really handy). In any > case, thanks for listening. 32-bit o/s aren't a factor as long as they support large files, which for all practical purposes, they do. (More precisely, we don't really support those very few systems, which are verging on archaic, that do not support large files.) -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/