Sleepycat Software wrote: > > One other comment, to state what's probably obvious -- the Huffman > encoding helps in two different ways: it not only reduces your disk space > requirements, but it also increases your page-fill-factor by increasing > the density of your data on the page. The compression during I/O scheme > only helps with disk space, it does nothing to increase the density of > information on the page. It will, however, help more with disk space than > the Huffman scheme will. > > It seems to me that any scheme to increase the density on the page is > going to require per key/data decompression in the comparison function. I've been following the discussion over the weekend and I am not sure if I missed something, but... It seems to me that if the keys are huffman encoded before they are given to the database (both at insertion time and at lookup time) you'd get the best of both worlds: smaller keys and no need to decode when comparing keys. You wouldn't be able to pack some of the data into the key, but I am not sure how exactly that would be beneficial anyway. -- Andrew Scherpbier <[EMAIL PROTECTED]> Contigo Software <http://www.contigo.com/>
begin:vcard n:Scherpbier;Andrew tel;fax:+1 619-278-2502 tel;work:+1 619-278-2329 x115 x-mozilla-html:FALSE url:http://www.contigo.com/ org:Contigo Software<br><img src="http://www.contigo.com/gifs/logo.gif">;Research & Development version:2.1 email;internet:[EMAIL PROTECTED] title:Vice President R&D note:<a href="http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=8334+Clairemont+Mesa+Blvd.&csz=San+Diego%2C+CA+92111&Get+Map=Get+Map">Yahoo Map</a> adr;quoted-printable:;;8334 Clairemont Mesa Blvd.=0D=0ASuite 204;San Diego;CA;92111;USA x-mozilla-cpt:;26848 fn:Andrew Scherpbier end:vcard
