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

Tom Lane wrote:
>
> Joseph Shraibman <jks(at)selectacast(dot)net> writes:
> >> 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?
>
> Yes.
>
> > 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?
>
> The original plan for 7.1 was "WAL from Vadim, plus whatever the rest of
> us get done meanwhile". Vadim's taken longer than expected, that's all.
> (He's had a few distractions, like a new wife...)
>
> There was some thought of maybe releasing 7.1 without WAL, but we're
> pretty much committed now --- the WAL changes are halfway-integrated in
> CVS, and backing them out would take more effort than it seems worth.
>

Um, so you can't just leave the code in there but put ifdefs so it
doesn't get compiled? Or just don't put in the documentation
instructions on how to enable WAL so nobody tries to run it?

I'm not complaining, just wondering what goes on behind the scenes.

And do you really think that WAL is more important that TOAST? I
imagine a good percentage of users bump up against the 8K limit and end
up with corrupted data (like I did) but much fewer think that WAL is a
critical feature.

--
Joseph Shraibman
jks(at)selectacast(dot)net
Increase signal to noise ratio. http://www.targabot.com