> > The big question is do we want to drop the target tuple  size down
> > 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
> > 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
> > 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
> 16x: currently 513 bytes fits in heap and takes (roughly) 513 
> bytes;

No, you misunderstood. Bruce was suggesting changing the target to 512.
That means if a row is wider than ~2k, toaster will try to toast until
the base row is
~512 bytes. I would not do that part for 8.3. 

> 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.

No, allowing one toast chunk to fill a page does not mean that every
chunk uses a whole page. 


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to