Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!lll-crg!gymble!umcp-cs!aplcen!osiris!eric
From: eric@osiris.UUCP (Eric Bergan)
Newsgroups: net.database
Subject: Re: Btree Question...
Message-ID: <856@osiris.UUCP>
Date: Fri, 18-Jul-86 08:10:41 EDT
Article-I.D.: osiris.856
Posted: Fri Jul 18 08:10:41 1986
Date-Received: Sat, 19-Jul-86 04:12:29 EDT
References: <151@itcatl.UUCP> <5303@ut-sally.UUCP> <164@ima.UUCP>
Organization: Johns Hopkins Hospital
Lines: 22

In article <164@ima.UUCP>, johnl@ima.UUCP (John R. Levine) writes:
> Both left and right hand key compression are useful ways to cram more entries
> into a tree node, and there's no argument that in the usual case that it's
> more expensive to fetch a node from the disk than to process it once it's read
> in, they're a big win.  On the other hand, I have this blindingly fast Eagle
> disk drive lashed up to a very sluggish IBM PC, and the tradeoffs are not
> always what you'd assume.

	Actually, I have talked to a couple of different relational
database companies, and their studies indicate that key compression is
not a win. The reason for this is that yes, a disk access is normally
longer than the time necessary to uncompress, but since most of the
bigger systems try to cache the indices, there may not be a disk
access. Then the compression is a straight loss. Of course, compression
would mean you can get more index into the cache, but their studies
seem to argue that compression just does not speed up access time.


-- 

					eric
					...!seismo!umcp-cs!aplcen!osiris!eric