Re: Whatcha' wanta have?????

"Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:40E645FC.2000501@earthlink.net... > Neil Truby wrote: > > > "Dave Griffen" <dgriffen@nospam.finishline.com> wrote: > >> Back in February Madison asked for input as to what we want to > >> see in the IDS 9.6 release. Although this is almost certainly too > >> late for IDS 9.6 consideration, I don't know of a better forum to > >> request modifications. I've recently stumbled on something which > >> I'd like to see changed. Specifically, I think the following > >> limitations need to be dramatically increased. > >> > >> Table-Level Parameters (based on 2K page size) Maximum Capacity per > >> Table > >> Data rows per fragment 4,277,659,295 > >> Data pages per fragment 16,775,134 > >> Data bytes per fragment (excludes Smart Large Objects (BLOB, CLOB) > >> and > >>Simple Large Objects (BYTE, TEXT) created in Blobspaces) 33,818,671,136 > >> > >>Release notes on the IBM-Informix website show that these numbers have > >>remained unchanged from OnLine 5.02 up through and including IDS 9.40. > >> > >> I can only think that these parameters were an oversight with IDS > >> 9.4. After all, how practical can a 4TB chunk ever be if it can > >> only hold 32GB of any single table? > > > > I'm absolutely with you on this, Dave. Although I haven't *recently* > > discovered this - it bit me in the arse a few years ago - I still have to > > spend time on larger bases using fragmentation for a purpose it simply was > > not intended - splitting tables across dbspaces to get around the 32G > > tablespace limit. With all the raised limits of 9.40, I was astonished to > > find this hadn;t been addressed. > > You're not alone - the issue is being addressed. Specifically, you > can reasonably expect the next version of IDS to allow you to have > multiple fragments of a single table in any given dbspace - subject to > the usual caveats about future prognostication (such as any given > feature might not be there when the product is released). There are > some other changes afoot which will ease these problems, too. > > Note that a lot of the constraints above are based on the availability > of bits. Unless we changed from using 32-bit numbers to some larger > number of bits - whether that be 48 or 64 - it is not possible to > stuff more information into the storage. In many ways, it would have > been nice to be able to revamp everything with the large chunk > support, but backwards compatibility and in-place migration dictated > otherwise. (So, yes, other organizations could be used and would > work, but they would not be backwards compatible.) > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ 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. 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? 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. Dave Griffen