Re: [GENERAL] 8k limit

From: "Peter Garner" <peter(dot)garner(at)toward(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] 8k limit
Date: 1998-10-27 14:29:20
Message-ID: 199810271429.AA157878000@piglet.toward.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi! :-)

>Is there any chance of the 8k tuple limit going away in
>future releases of PostgreSQL? I was working on setting up
>a listserv archive with fields such as sentfrom, date,
>subject, and body, but the content of the body field would
>often exceed 8k because some people are just long-winded.
>I'd really rather not have to deal with the LO interface.

The LO interface is something of a pain, I admit. In
addition LOBS seem to take a minimum of 16K disk space and
can really slow things down since they are all stored in the
same directory. (Someone kindly pointed all of these things
out to me in the interfaces mailing list yesterday.)

I have a few ideas that may help. I am developing an
alternative to libpq++. It is nowhere near finished but
it does make dealing with LOBs MUCH easier. Of course you
must be using C++ for this to be of any value. ;-)

What I have decided to do, (I am also developing an article
archiver using postgres), is use both text and LOBS. I have
a table defined as :

create table Msg_Bodies
(
Msg_Id text not null ,
Msg_Oid OID ,
Msg_Text text ,

primary key ( Msg_Id )

) ;

If the article is longer than 8191 bytes, I create a LOB and
populate the Msg_Oid field with the OID of the LOB. If the
message is less than 8191 bytes, I simply insert that text
into the Msg_Text field. When retreiving records, I simply
check whether the oid or the text field is not null and
retreive the text appropriately. Of course to be really
safe one might define a rule requiring that EITHER the
Msg_Oid or the Msg_Text field be non null.

Thanks

Peter

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Will Luttrell 1998-10-27 18:39:24 (no subject)
Previous Message Sferacarta Software 1998-10-27 13:36:24 Re: