Re: Tablespace size
Question: does IDS 11 still impose the ~16 million page per-tablespace (single table fragment) limit? Answer from the group: yes, it does. The only workaround offered is to fragment the table so data is spread across multiple tablespaces, though participants noted this uses fragmentation to dodge a product limit rather than for its intended purpose. The rest of the thread is opinion/banter about whether this clashes with Informix's "set it and forget it" marketing and whether R&D should raise the limit; no fix or change beyond fragmenting is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Neil Truby wrote: > "Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message > news:mailman.291.1235126466.1831.informix-list@iiug.org... >> Neil Truby wrote: >>> "Obnoxio The Clown" <obnoxio@serendipita.com> wrote in message >>> news:mailman.290.1235123545.1831.informix-list@iiug.org... >>>> Neil Truby wrote: >>>>> Does the 16g page tabelspace maxiumum still apply in IDS 11 please? >>>> Yes. >>> >>> Thanks for the reply. >>> >>> That's quite a disappointment. >>> >>> I imagine that this is quite a fundamental thing to address, or it >>> would have been already, but I think Informix Development is going to >>> have to Grasp the Nettle on this. I find it becoming an increasingly >>> important factor in physical database design and administration. >>> Sure, you can fragment around it, but this doesn't chime well with >>> IBM's messaging about Informix ("Set it and Forget it", etc) ... >> >> 99% of DBA's /do/ just set it and forget it. Don't blame Informix for >> your ineptitude or laziness. > > Er, well, that's a bit harsh. I'm not blaming anyone for anything. I'm > saying that a limitation, which once probably seemed as unlikely ever to > be relevant as a 2g chunk size, is becoming more and more of a > consideration as time goes by. > > And that, although it's fairly simple for an Informix God such as myself > to workaround, the same is not necessarily true of others; that having > to use fragmentation not for its intended purpose but to get around an > increasingly wearisome product limitation is not consistent with the > "Low Maintenance" marketing message; and that it really needs to be > addressed. > > So, Bollocks to you and your uninformed opinion! (Which of course > though I fully respect as equally valid to mine). How many rows does it translate to? What is the page size? With tables of this size, I think fragmentation can become a blessing for a lot of reasons... This change would not be trivial to implement. I hope that if one day R&D decides to do it, they take the opportunity to change other things... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
Fernando Nunes wrote: > With tables of this size, I think fragmentation can become a blessing for a lot > of reasons... You would have thought so. But then setting it and forgetting it is obviously *much* more important. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
Obnoxio The Clown wrote: > Fernando Nunes wrote: >> With tables of this size, I think fragmentation can become a blessing >> for a lot of reasons... > > You would have thought so. But then setting it and forgetting it is > obviously *much* more important. > I don't think we're "there yet"... I mean, "set it and forget it" for systems with these sizes (unless you set it with fragmentation and then forget it ;). But Neil has a point. We want to get there. We have other limitations that time showed were too small. I don't think this is the same case, but it would be nice to don't have to worry about it before time prove me wrong... Maybe there's something in the roadmap that point in that direction... For the time being I believe systems with this size will have a DBA... Maybe not a full time one, but at least in the planning phase. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
"Fernando Nunes" <domusonline@gmail.com> wrote in message news:gnm6hd$2j2$1@news.motzarella.org... > How many rows does it translate to? What is the page size? > With tables of this size, I think fragmentation can become a blessing for > a lot of reasons... Many millions. Tens of millions. 2k. But I've already had it once this year on an AIX (4k page) system too ... > This change would not be trivial to implement. I hope that if one day R&D > decides to do it, they take the opportunity to change other things... I'm surprised that you don't think it's important. Less surprised at Obnoxio - I doubt if he ever really administers any proper systems, and his kitchen inventory system running on IDS 11 hasn't hit any limits yet ;-) To me, it's more of an irritaion than a serious issue - just like 2g chunks actually! But then I'm not advertising Informix as "Set and Forget" (a strapline which, as a database services compnay, we don't really like much anyway!). rgds Neil
Neil Truby wrote: > "Fernando Nunes" <domusonline@gmail.com> wrote in message > news:gnm6hd$2j2$1@news.motzarella.org... > >> How many rows does it translate to? What is the page size? >> With tables of this size, I think fragmentation can become a blessing for >> a lot of reasons... > > Many millions. Tens of millions. 2k. But I've already had it once this > year on an AIX (4k page) system too ... > >> This change would not be trivial to implement. I hope that if one day R&D >> decides to do it, they take the opportunity to change other things... > > I'm surprised that you don't think it's important. Less surprised at > Obnoxio - I doubt if he ever really administers any proper systems, and his > kitchen inventory system running on IDS 11 hasn't hit any limits yet ;-) > > To me, it's more of an irritaion than a serious issue - just like 2g chunks > actually! > > But then I'm not advertising Informix as "Set and Forget" (a strapline > which, as a database services compnay, we don't really like much anyway!). > > rgds > Neil > > Don't get me wrong... I think it is important. Personally I never hit this limit. I know of customer(s?) who did. I just think that when this happens, we're talking about systems that by no means are the "set and forget" kind... For several reasons. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...