From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using storage MAIN |
Date: | 2004-01-16 02:32:30 |
Message-ID: | 26471.1074220350@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)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 tuple doesn'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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-01-16 02:37:17 | Re: Make SHOW command subqueriable? |
Previous Message | Kris Jurka | 2004-01-16 02:22:26 | Re: Make SHOW command subqueriable? |