Informix storage limits
Benjamin Thompson asked for votes on RFEs to HCL to lift the limit of 16,775,134 data pages per fragment and 255 rows per page. Hal Maner said the page limit RFE was probably his and earlier feedback was that it was unlikely. Art Kagel explained that raising it would need a larger row address than the current 32-bit ROWID. No decision in the thread.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi community, I am trying to raise the profile within HCL of a couple of issues related to how Informix stores data on disk and get them on the Informix roadmap. If you have a large system you will be familiar with them already I am sure. They are the Informix data pages per fragment limit of 16,775,134 and the rows per page limit of 255 rows per page. My opinion is that these limits are going to be more of a problem in the future as a lot of well-established systems are only getting bigger and there is a trend towards Big Data. The first is the most serious as, if you reach this limit for any table or table partition, no-one can no longer insert any data and dealing with the issue is often not straightforward or quick. Even if you don't ever have a catastrophe, planning around them, putting in place the necessary monitoring and re-organising tables affected can be a drain on DBA time and cause downtime for your business. I have updated someone else's existing RFE with more information regarding the pages per partition limit: https://ibm-data-and-ai.ideas.aha.io/ideas/INFX-I-31 And raised my own RFE about the rows per page limit: https://ibm-data-and-ai.ideas.aha.io/ideas/INFX-I-374 I would be grateful if you could vote for one or both of them. Thank you, Ben. ------------------------------ Benjamin Thompson ------------------------------ #Informix
Yes, that existing RFE on pages per fragment limit is probably the one I put out there a while back and the initial feedback I received was that it was not likely to get done, yet I agree this is an important limitation to get rid of. I will vote for the other one as well. I hope they get into the plans to address. Hal Maner M Systems International, Inc.
I remember Scott discussing this years ago, he wanted to make every fragmented by default as he claimed it would easier to add more fragments at a later date. He usually knew what he was taking about Cheers Paul
It would be good in Workgroup edition if use of partitioning for reasons of storage space was separated from PDQ, detach/drop, fragment elimination and other benefits of having Enterrprise Edition, otherwise this solution is only available to a small portion of users. ------------------------------ Benjamin Thompson ------------------------------
The problem is that to change the number of pages in a data partition beyond 2^24 one would have to change the ROWID to something similar to the ifx_row_id which is <partnum>:<rowid>. Perhaps a partnum:pagenum:slotnum with a 32bit partnum and pagenum and a 16bit slotnum rather than the 24bit page number and 8bit slot number. But that's a major change from a 32bit row address to an 80bit row address. Currently indexes on partitioned tables use ifx_row_id but indexes on non-fragmented tables use the simple rowid. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.