Sorry for replying to my own email, but I've just stumbled upon an article
that seems to imply that v7.1 will support unlimited record lengths. Is
this the case? When is v7.1 due for release? Is a beta available?
Thanks.
Gordan
----- Original Message -----
From: "Gordan Bobic" <gordan@freeuk.com>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, November 28, 2000 10:36 AM
Subject: [GENERAL] Tuple size limits and upgrading
> Hi!
>
> I've got a bit of a problem with tuple size limits. They seem to be
limited
> to 8K, which is not enough for me, in the current application. Ideally,
I'd
> like to bump this up to at least 256K, although 512K would be nice. This
is
> for the purpose of storing large text fields, although it's usefulness
> might be extended for storing binary data as well (e.g. large images).
>
> Is there a way to allow records (tuples) to have arbitrary size?
>
> A fair majority of the text files I am storing in the database fits into
> records despite the 8K limit. However, there is a substantial number of
> those that don't. The biggest ones can go up to 512KB and beyond, but
this
> is somewhat uncommon.
>
> I have read in the archives that this can be modified by changing a few
> parameters and re-compiling. What is the limit to which the record size
can
> be increased? Does this setting seriously hammer performance (even if
there
> are only comparatively few records of this size)?
>
> The problem is that I would like to keep the way things are working,
> including directory structures, and I am not sure how to do this if I
> re-compile from source, as that will put everything into /usr/local.
>
> I am running RH Linux 6.2, upgraded to PGSQL 7.0.1, and files are in
> /var/lib/pgsql and /usr/lib/pgsql, and non-/usr/local locations.
>
> How can I upgrade to a customized version of 7.0.3 while keeping all the
> files in the same place? I know I can use the SRPM distribution, but just
> doing rpm --rebuild doesn't let me tweak the parameter in need to change.
>
> Can anybody suggest a way of doing this?
>
> Thanks.
>
> Gordan
>
>
>
