Re: RFC: Constant Database Support

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Mar 20, 2010 at 10:01:44PM +0000, Christos Zoulas wrote:
> In article <20100320161206.GA7391%britannica.bec.de@localhost>,
> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
> >On Sat, Mar 20, 2010 at 08:19:39AM -0700, Matt Thomas wrote:
> >> Any reason you didn't consider implementing CBR as a backend for the
> >db in libc?  
> >
> >The dbopen(3) API can be provided on top of CDB, but it doesn't fit too
> >well with many of use cases e.g. in libc. The services(5) database is a
> >good example. There are multiple keys for entry and the db
> >implementation essentially emulated this by using an aritifical key for
> >the main entry and doing a double lookup for all keys. As the keys are
> >part of the data, the overall disk space usage is essentially doubled.
> 
> Well, I don't see the difference really. Most of the entry points are
> the same, no?

The main difference is where the key storage happens. The db(3) API
essentially includes the key match, the cdbr(3) API doesn't. That means
more flexiblity as the key can be part of the data or synthesized from
it. For services(5), the key is either the port number or one of the
service names, optionally including the protocol. For db(3), it adds all
the permutations as key with the synthetic index number as value. For
cdbr(3) it has multiple key entries, but those are not stored on disk.
The returned value is the only possible match, but it is up to the
caller to validate it. So depending on the lookup routine, it checks the
different parts directly. For getservbyport it is always as fast as the
db(3) check, for getservbyname it might in theory be slower if there are
lots of aliases and this is actually a miss. Doesn't make much of a
difference for a hit.

Joerg