Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!tektronix!uw-beaver!ssc-vax!bcsaic!michaelm
From: michaelm@bcsaic.UUCP
Newsgroups: net.database
Subject: Ingres text fields (was: Re: speed of ORACLE, large INFORMIX DBMS's)
Message-ID: <590@bcsaic.UUCP>
Date: Thu, 3-Jul-86 13:41:15 EDT
Article-I.D.: bcsaic.590
Posted: Thu Jul  3 13:41:15 1986
Date-Received: Sun, 6-Jul-86 01:07:28 EDT
References: <449@oracle.UUCP> <235@hdsvx1.UUCP>
Reply-To: michaelm@bcsaic.UUCP (michael maxwell)
Organization: Boeing Computer Services AI Center, Seattle
Lines: 18

In article <235@hdsvx1.UUCP> hoffman@hdsvx1.UUCP (Richard Hoffman) writes:
>Ingres does offer primitive data compression for text strings (the supress 
>trailing blanks and nulls using run-length compaction) in the base tables
>themselves, not just the indexes.  This can be of great utility in a long
>text field (such as an abstract) that you do not intend to query directly.

Long text strings?  I've wanted that... Our documentation (dated Dec. 1977!)
says that a tuple can only be 498 bytes (512 byte pages - overhead), so a text
field could only be 498 bytes long (and then only if you were willing to limit
yourself to one text field in the tuple, clearly not a practical situation).
The version of Ingres we (are going to) use is quite a bit more recent than
that (I don't have the date right here); it is a "public domain" version, not
the commercially available version.  Has the 498 byte limit been overcome 
in more recent versions of Ingres?
-- 
Mike Maxwell
Boeing Artificial Intelligence Center
	...uw-beaver!uw-june!bcsaic!michaelm