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 decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
