Re: Any risk in increasing BLCKSZ to get larger tuples?

Tom Lane wrote:
>
> Philip Hallstrom <philip@adhesivemedia.com> writes:
> > larger than the builtin limit for tuples.  Is there anything I should be
> > aware of before changing the below value and recompiling?
>
> Only that it will force an initdb.  Note the 32k limit, too.
>
> A trick you can use in 7.0.* to squeeze out a little more space is
> to declare your large text fields as "lztext" --- this invokes
> inline compression, which might get you a factor of 2 or so on typical
> mail messages.  lztext will go away again in 7.1, since TOAST supersedes
> it,

Uh, why.  Does TOAST do automatic compression?  If people need to store
huge blocks of text (like a DNA sequence) inline compression isn't just
a hack to squeeze bigger text into a tuple.

>
> > Also, it looks like the TOAST stuff would solve this (right/wrong?), but
> > it's not going to be ready for 7.1 (right/wrong?)
>
> Right, and wrong.  It's been done for months...
>

I've been wondering why we haven't seen 7.1 before now then.  I mean why
are you waiting on whatever you are waiting on?  Why not release 7.1 now
and 7.2 in January with all the other features you want to add?


--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio.  http://www.targabot.com