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

Re: TOAST usage setting

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>,"Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "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-05 09:41:36
Message-ID: E1539E0ED7043848906A8FF995BDA579021B3113@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> > 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;

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. 

Andreas

In response to

Responses

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2007-06-05 09:45:54
Subject: Re: libpq and Binary Data Formats
Previous:From: NikhilSDate: 2007-06-05 09:20:23
Subject: Re: CREATE TABLE LIKE INCLUDING INDEXES support

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