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

Philip Hallstrom wrote:
>
> [stuff about why 7.1 isn't out and the 8K limit and TOAST AND WAL snipped]
>
> > 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.
>
> If I had to pick I would rather have WAL over TOAST. I originally asked
> the question about BLCKSZ and this is the first app that I am worried
> about hitting that limit. It's actually never even crossed my mind before
> this since usually if it's big it's an image and I just store it on disk
> with a filename in the database.

That is what I'm doing now, but only because the 8k limit forced me to.
It adds kludge to the code, and when I was deleting entries to the
database, in order to make sure there weren't orphaned files around
(disk space leak) I would have had to read in the table entry, get the
filenames, delete the files, then delte the table entry. Since deltes
are rare for me I decided not to worry about that until TOAST came
along.

And I would say for a lot of web uses 8K
> (or the 32K max) is way more than adequate.

A lot, but for a lot MySQL is adequate. For a lot it isn't. And if 8K
isn't adequate there is nothing you can do about it (except recompile of
course, but then you still have a limit).

> WAL on the other hand would be really nice because even if my data
> is small, it sure would be nice to reproduce it in the case of a monstrous
> crash.

Nice, but not neccessary. That is my point. I would think more people
would consider TOAST neccessary than WAL because running into the 8k
limit (or 32k limit) will be a showstopper. Granted some people NEED to
make sure no data is lost, but since WAL isn't ready yet and TOAST is,
why not release 7.1 now and release 7.2 in January with WAL?

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