Re: Any risk in increasing BLCKSZ to get larger tuples? - Mailing list pgsql-general

From Neil Conway
Subject Re: Any risk in increasing BLCKSZ to get larger tuples?
Date
Msg-id 20001018182428.B1032@klamath.dyndns.org
Whole thread Raw
In response to Any risk in increasing BLCKSZ to get larger tuples?  (Philip Hallstrom <philip@adhesivemedia.com>)
Responses to_char function  (Yohans Mendoza <yohans@demiurge.sirius-images.net>)
List pgsql-general
On Wed, Oct 18, 2000 at 02:46:36PM -0700, Philip Hallstrom wrote:
>     I'm thinking about using postgres for an app that will store
> various email messages which might (although probably not likely) be
> larger than the builtin limit for tuples.  Is there anything I should be
> aware of before changing the below value and recompiling?
>
> 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. TOAST will solve this, and it will be ready for 7.1. It's
in the current sources, BTW (I'm developing an app which uses it and I
haven't had any problems working with Postgres from CVS).

I've heard that people sometimes run into problems setting BLCKSZ to
32K - I'd suggest staying under 30K.

BTW, although most emails are < 8K, some could be > 1 meg (attachments,
deliberate attempts to cause problems). So increasing BLCKSZ isn't
the only thing you can do. Perhaps the best solution would be to
determine BLCKSZ at runtime (possible?), and then either reject
stuff > than that, or store it as a LO.

HTH,

Neil

--
Neil Conway <neilconway@home.com>
Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc
Encrypted mail welcomed

Whoever you are -- SGI, SCO, HP, or even Microsoft -- most of the
smart people on the planet work somewhere else.
        -- Eric S. Raymond

Attachment

pgsql-general by date:

Previous
From: Philip Hallstrom
Date:
Subject: Any risk in increasing BLCKSZ to get larger tuples?
Next
From: Nate Lawson
Date:
Subject: MySQL PASSWORD('x') function workalike