Path: utzoo!attcan!uunet!lll-winken!ames!haven!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP (Stuart Gathman)
Newsgroups: comp.mail.uucp
Subject: Re: Making /usr/lib/uucp/paths a _binary_ database
Summary: a btree works
Keywords: pathalias UUCP smail
Message-ID: <148@bms-at.UUCP>
Date: 10 Jan 89 20:44:26 GMT
References: <486@fallst.UUCP> <490@gonzo.UUCP>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 26

In article <490@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes:
> In article <486@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes:
> >I'm not very proficient at C, but it seems that since 'paths' is
> >essentially a two-field set of records it ought not be terribly
> >hard to make 'pathalias' generate a binary database file.

> The first question is "what you would gain?"  The only obvious overhead
> in the existing format are the \n separator between records and a one
> character field separator.

Use a (good) btree (not isam) with leading duplicate compression and
variable length records and keys.  Use only the unique portion of the
keys.  Store the path section with leading duplicate
compression compared to the previous record in key sequence.  (This works
well on our system, a more complicated method might be necessary for sites
with a large number of connections.)  This cuts the size in half, reduces
seeks to three, and takes less CPU to boot.  (Using our propietary Btree
system; the unique key & leading dup compression are done automatically.  
Sorry, no source. :-( )

A system for sites with large numbers of nodes might assign a binary number
to neighboring site names (or the first few tree levels) for storing
the paths.
-- 
Stuart D. Gathman	<stuart@bms-at.uucp>
			<..!{vrdxhq|daitc}!bms-at!stuart>