On Fri, Jun 01, 2007 at 01:50:12PM -0400, Bruce Momjian wrote: > I think the long-term solution is to go to a 2k/8k fragment/block model, > but that isn't going to happen for 8.3. There might well have been lessons learned since UFS (anyone know what ZFS does in this regard?), but I agree that we want to be able to do a mix of full chunks and fragments.
> The big question is do we want to drop the target tuple size down to > 512, and increase the chunk size to 8k for 8.3? Dropping the tuple size > down to 512 is going to give us some smaller TOAST values to fill in > free space created by the 8k chuck size, assuming you have both types of > values in the table. Do we want to increase the access time of long > TOAST by 6% if it means having more wasted space for lots of 4.1k > values? If we do that people could see their disk space usage increase by up to 16x: currently 513 bytes fits in heap and takes (roughly) 513 bytes; if we make that change it would then get toasted and take 8K. I don't think we want to do that. Disk space aside, it's almost certain to seriously hurt performance as soon as you don't fit entirely in memory. How big is the hit for setting both to 512? Also, is this something that could be set at initdb instead of compile time? That would make it easier for folks to go back to old behavior if the needed to... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
pgpzcxY6b7mU2.pgp
Description: PGP signature