Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id MAA30440
	for <pgsql-interfaces@postgreSQL.org>;
	Tue, 26 Oct 1999 12:20:17 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA23188;
	Tue, 26 Oct 1999 12:16:49 -0400 (EDT)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: "'stuart@comodo.net'" <stuart@comodo.net>, pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] 8k limit 
In-reply-to: Your message of Tue, 26 Oct 1999 15:31:24 +0200
	<1BF7C7482189D211B03F00805F8527F748C1BC@S-NATH-EXCH2>
Date: Tue, 26 Oct 1999 12:16:49 -0400
Message-ID: <23186.940954609@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> The 8kB limit you are refering to is probably the tuple-length limit.  This
> can be altered to a maximum of 64kB (I think, might only be 32kB),

32k; otherwise Michael's comments are accurate.

>>> been discussed here before =). Next question is whats the 
>>> max number of large
>>> objects you can store? I think its about 4 billion , am i wrong?

Each LO results in the creation of two files in your database directory,
which means performance will get pretty horrible when you get past a
few thousand LOs (at least on most flavors of Unix, which are not
optimized for huge directories).

There has been discussion of fixing this, eg by making a subdirectory
tree for LOs, but I'd rather see us put our effort into eliminating
the tuple length limit.

			regards, tom lane