Re: page size of chunk in fragmented table
On Aug 6, 4:03 pm, "Jack Parker" <jack.park...@verizon.net> wrote: > It depends. Benchmark with the different page sizes and see what floats > your boat. Don't forget to also modify the bufferpool settings in your > $ONCONFIG to reflect your choices. > > j. > > -----Original Message----- > From: informix-list-boun...@iiug.org > > [mailto:informix-list-boun...@iiug.org]On Behalf Of > mohitanch...@gmail.com > Sent: Monday, August 06, 2007 3:26 PM > To: informix-l...@iiug.org > Subject: page size of chunk in fragmented table > > Version: IDS 10 > > We are fragmenting table which currently is in one dbspace with 8K as > page size. Now since we are fragmenting I wanted to ask: > 1. Should we reduce the page size or keep it same > 2. Which one is better, small page size or large page size > > This table grows and will eventually have 50 M rows. We also have > blobs in tablespace. > > _______________________________________________ > Informix-list mailing list > Informix-l...@iiug.orghttp://www.iiug.org/mailman/listinfo/informix-list No problem Art...I've been called worse... For the record, I'm not a huge fan of "large pages" necessarily. Art has heard/seen my presentations touting some of the benefits of large pages, BUT, as he accurately points out, it really depends a number of things. For index pages, there is no 255 row limitation, so having larger pages will reduce the overhead per page and, all things equal, reduce the overall size of the b+tree. For data rows, yes, it depends on the row size. Art again accurately points out that 2016 is the largest row you can have on a 2K data page (2048-28-4; 2048 is the page size; 28 is the pg header plus pg trailing timestamp (24+4); the 4 is the slot table entry for that row). IF your rows are larger than that, a larger row would fit on one page of an appropriate size, versus having a remainder page or more, etc. In my travels of 2005, I finally had 1 client in Costa Mesa that said that they had put their tables in a larger page size dbspace (due to long rows), and their indexes (one to all) in a smaller page size dbspace, and saw tremendous improvement. This makes sense. I have a presentation of CPS (configurable page sizes) that has a couple of proofs (or more) that put numbers to the reality of the overhead and chaining, etc. I'll post it at some point, OR, you can contact me directly to get it at mail@markscranton.com. HTH - Mark Scranton