RE: system page size!

I would like to point out that even with 255 rows per 'page' that translates to (don't forget header info): rowsize=7 for a 2K page rowsize=15 for a 4K page rowsize=31 for an 8K page Don't know about you, but 15 is an awfully small row (granted I DO have a 10GB table with a rowsize of 11 and I would love to not be wasting those 4 bytes per record - however that table used to be 75GB before I redesigned it - I should be happy). You can also set your own page size with versions 7(?), 8 and 9. cheers j. (who backed off on the 8K page size for the 4K) > -----Original Message----- > From: Jonathan Leffler [mailto:jleffler@informix.com] > Sent: Thursday, January 11, 2001 5:18 PM > To: informix-list@iiug.org > Subject: Re: system page size! > > > Murat YILDIZ wrote: > > I am confused with the system page size, now? > > Where can I see what system page size informix is using? > > > > The last line of onstat -b tells me 2048 buffer size.... > > but on HP-UX dmesg shows this: > > physical page size = 4096 bytes, logical page size = 4096 bytes > > > > Is this physical page size something else? > > There are multiple pages sizes available to confuse the unwary (or the > inquisitive). > > Informix is using logical pages of 2 KB (onstat -b), which is > the normal > Informix page size on most systems. At the time when it was > instituted > (1988?), most operating systems were using a 1 KB or 2 KB > page size, so > Informix's page size was a multiple of the system page size, which was > good. Over time, the operating systems increased their page > size from 1 > or 2 to 4 KB, but Informix was unable to change its page size to match > for a variety of reasons. These include the problems of forwards and > backwards migration -- rewriting an entire database is a slow > process -- > and the fact that it is easier to waste space with internal > fragmentation on a 4 KB page. By that, I mean that if you > have a a row > size smaller than ((4096 - 28) / 255 - 4) or 11 bytes (eg a > cross-reference table with 2 INTEGER values, each referencing rows in > another table), then you are stuck with just 255 rows per page, even > though if you were not limited by the slot numbering, you could fit in > more than 255 rows. So, I don't know of any platform where there was > initially a 2 KB page version of OnLine which subsequently > changed to a > 4 KB page size. I believe XPS 8.3x does provide variable size pages. > > What does the page size mismatch mean? Probably not very much. ...I > don't like the conclusion I'm coming to, so I'm not sure whether I'm > right... In the worst case (a cooked file), when OnLine reads a 2 KB > page, the o/s reads 4 KB from disk and transfers 2 KB of that to > Informix's shared memory cache. If it needs the next 2 KB before it > removes the (o/s) page from the (o/s) cache, then no further disk read > is needed. If the user writes to the page after the o/s > clears the page > from its cache, then it has to reread the 4 KB page, modify the 2 KB > from the Informix cache, and then write back the 4 KB page. Similar > rules might apply to raw disk devices too; the o/s will read 4 KB, > return the relevant 2 KB to Informix, and discard (actually > discard) the > other 2 KB. Hmmmm, I wonder how much of a performance boost would be > available if we resized the Informix pages to match (or > exceed) the o/s > page size. If I were redesigning the Informix page layouts, > I'd use big > pages (like 64 KB) with 8 byte rowids and 16-bit slot > numbers. For the > immediately foreseeable future, that would be bigger than the o/s page > size, and therefore would not require the discarding of pages. > > And, going back to the original question, the fact that the > o/s uses one > page size and Informix uses another does not cause confusion to either > piece of software because they are referring to different > sorts of pages > (though it may cause some extra work for the o/s). > > -- > Yours, > Jonathan Leffler (Jonathan.Leffler@Informix.com) #include > <disclaimer.h> > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > "I don't suffer from insanity; I enjoy every minute of it!" >

Jack, pagesize os ONLY configurable by the DBA in XPS (8.xx). As Jonathan stated in 6.x, 7.x, & 9.x it is fixed at 2K for all platforms except AIX and NT which are fixed at 4K. The ONLY other version of Informix I am aware of that EVER had a pagesize difference than 2K was the old Turbo engine on Amdahl mainframes where it was 4K as well. In 5.xx there was an ONCONFIG parameter, PAGESIZE, which you could set at your own peril at init time to set the pagesize, however, many folk at Informix warned me that noone was sure that that parameter was being properly and consistently used everywhere in the code and that trouble including data loss might follow changing PAGESIZE from its default value or 2048. Art S. Kagel "Parker, Jack" wrote: > > I would like to point out that even with 255 rows per 'page' that translates > to (don't forget header info): > > rowsize=7 for a 2K page > rowsize=15 for a 4K page > rowsize=31 for an 8K page > > Don't know about you, but 15 is an awfully small row (granted I DO have a > 10GB table with a rowsize of 11 and I would love to not be wasting those 4 > bytes per record - however that table used to be 75GB before I redesigned it > - I should be happy). > > You can also set your own page size with versions 7(?), 8 and 9. > > cheers > j. > (who backed off on the 8K page size for the 4K) > > > -----Original Message----- > > From: Jonathan Leffler [mailto:jleffler@informix.com] > > Sent: Thursday, January 11, 2001 5:18 PM > > To: informix-list@iiug.org > > Subject: Re: system page size! > > > > > > Murat YILDIZ wrote: > > > I am confused with the system page size, now? > > > Where can I see what system page size informix is using? > > > > > > The last line of onstat -b tells me 2048 buffer size.... > > > but on HP-UX dmesg shows this: > > > physical page size = 4096 bytes, logical page size = 4096 bytes > > > > > > Is this physical page size something else? > > > > There are multiple pages sizes available to confuse the unwary (or the > > inquisitive). > > > > Informix is using logical pages of 2 KB (onstat -b), which is > > the normal > > Informix page size on most systems. At the time when it was > > instituted > > (1988?), most operating systems were using a 1 KB or 2 KB > > page size, so > > Informix's page size was a multiple of the system page size, which was > > good. Over time, the operating systems increased their page > > size from 1 > > or 2 to 4 KB, but Informix was unable to change its page size to match > > for a variety of reasons. These include the problems of forwards and > > backwards migration -- rewriting an entire database is a slow > > process -- > > and the fact that it is easier to waste space with internal > > fragmentation on a 4 KB page. By that, I mean that if you > > have a a row > > size smaller than ((4096 - 28) / 255 - 4) or 11 bytes (eg a > > cross-reference table with 2 INTEGER values, each referencing rows in > > another table), then you are stuck with just 255 rows per page, even > > though if you were not limited by the slot numbering, you could fit in > > more than 255 rows. So, I don't know of any platform where there was > > initially a 2 KB page version of OnLine which subsequently > > changed to a > > 4 KB page size. I believe XPS 8.3x does provide variable size pages. > > > > What does the page size mismatch mean? Probably not very much. ...I > > don't like the conclusion I'm coming to, so I'm not sure whether I'm > > right... In the worst case (a cooked file), when OnLine reads a 2 KB > > page, the o/s reads 4 KB from disk and transfers 2 KB of that to > > Informix's shared memory cache. If it needs the next 2 KB before it > > removes the (o/s) page from the (o/s) cache, then no further disk read > > is needed. If the user writes to the page after the o/s > > clears the page > > from its cache, then it has to reread the 4 KB page, modify the 2 KB > > from the Informix cache, and then write back the 4 KB page. Similar > > rules might apply to raw disk devices too; the o/s will read 4 KB, > > return the relevant 2 KB to Informix, and discard (actually > > discard) the > > other 2 KB. Hmmmm, I wonder how much of a performance boost would be > > available if we resized the Informix pages to match (or > > exceed) the o/s > > page size. If I were redesigning the Informix page layouts, > > I'd use big > > pages (like 64 KB) with 8 byte rowids and 16-bit slot > > numbers. For the > > immediately foreseeable future, that would be bigger than the o/s page > > size, and therefore would not require the discarding of pages. > > > > And, going back to the original question, the fact that the > > o/s uses one > > page size and Informix uses another does not cause confusion to either > > piece of software because they are referring to different > > sorts of pages > > (though it may cause some extra work for the o/s). > > > > -- > > Yours, > > Jonathan Leffler (Jonathan.Leffler@Informix.com) #include > > <disclaimer.h> > > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > > "I don't suffer from insanity; I enjoy every minute of it!" > >