Re: Using storage MAIN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Using storage MAIN
Date
Msg-id 26471.1074220350@sss.pgh.pa.us
Whole thread Raw
In response to Using storage MAIN  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Quick question about how column storage works.  If you set a TEXT field 
> to be storage MAIN, does this place a limit on the amount of data that 
> can be stored in the row (eg. 8k?)

No, because it will still be forced out-of-line if that's the only way
to make the row fit.  The source code comments may be helpful:
   /*----------    * attstorage tells for VARLENA attributes, what the heap access    * methods can do to it if a given
tupledoesn't fit into a page.    * Possible values are    *        'p': Value must be stored plain always    *
'e':Value can be stored in "secondary" relation (if relation    *             has one, see pg_class.reltoastrelid)    *
      'm': Value can be stored compressed inline    *        'x': Value can be stored compressed inline or in
"secondary"   * Note that 'm' fields can also be moved out to secondary storage,    * but only as a last resort ('e'
and'x' fields are moved first).    *----------    */
 

You could force no-compression, no-out-of-line semantics by setting it
to PLAIN, and then it *would* fail if over 8K.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Make SHOW command subqueriable?
Next
From: Christopher Kings-Lynne
Date:
Subject: Log rotation for pg_autovacuum