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

Tom Lane wrote:
>
> Philip Hallstrom <philip(at)adhesivemedia(dot)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(at)selectacast(dot)net
Increase signal to noise ratio. http://www.targabot.com