Re: Whatcha' wanta have?????
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/
Thanks for the feedback Jonathan. It's good to know this is being addressed. "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/