> > 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
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.
In response to
pgsql-hackers by date
|Next:||From: Richard Huxton||Date: 2007-06-05 09:45:54|
|Subject: Re: libpq and Binary Data Formats|
|Previous:||From: NikhilS||Date: 2007-06-05 09:20:23|
|Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support|