Skip site navigation (1) Skip section navigation (2)

Re: TOAST usage setting

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>,Gregory Stark <stark(at)enterprisedb(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TOAST usage setting
Date: 2007-06-04 21:18:03
Message-ID: 20070604211803.GG92628@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)decibel(dot)org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-06-04 22:18:17
Subject: Re: syslogger line-end processing infelicity
Previous:From: Gregory StarkDate: 2007-06-04 20:59:12
Subject: Re: Implicit casts with generic arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group