From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Yang Zhang <yanghatespam(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Subject: | Re: Compression |
Date: | 2011-04-15 02:42:01 |
Message-ID: | 201104141942.02384.adrian.klaver@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thursday, April 14, 2011 5:51:21 pm Yang Zhang wrote:
> >
> > adrian(dot)klaver(at)gmail(dot)com
>
> Already know about TOAST. I could've been clearer, but that's not the
> same as the block-/page-level compression I was referring to.
I am obviously missing something. The TOAST mechanism is designed to keep tuple
data below the default 8KB page size. In fact it kicks in at a lower level than
that:
"The TOAST code is triggered only when a row value to be stored in a table is
wider than TOAST_TUPLE_THRESHOLD bytes (normally 2 kB). The TOAST code will
compress and/or move field values out-of-line until the row value is shorter than
TOAST_TUPLE_TARGET bytes (also normally 2 kB) or no more gains can be had.
During an UPDATE operation, values of unchanged fields are normally preserved as-
is; so an UPDATE of a row with out-of-line values incurs no TOAST costs if none
of the out-of-line values change.'
Granted no all data types are TOASTable. Are you looking for something more
aggressive than that?
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Yang Zhang | 2011-04-15 02:46:34 | Re: Compression |
Previous Message | Bosco Rama | 2011-04-15 02:33:17 | Cross-schema view issue/question |