(temorary) solution for the database index problems ?!?!

 * The first report came from Tony Bates (You probably still remember him
 * ;-)) and most of the discussion was done on the 'db-wg' mailing list
 * (true this subject belongs more on rr-impl). We more or less (wrongly?)
 * assumed that you were on that mailing list and that if Tony had this
 * problem it was something new ...

Well, I seem to have dropped off most mailing lists.... Please put me
back on db-wg...

 *  * way DBM grows its datafiles. It basically is rather stupid when it needs
 *  * more space and will take an increasing chunk of disk space for the
 *  * index. Not using the -p option will only be a temporary measure, only
 *  * because you make the database smaller (no prime entries) but you do
 *  * make it flatter. Try and make or run a perl with sdbm or gdbm. These
 *  * two have better size control than the standard dbm (esp gdbm) but are
 *  * slower when indexing.
 * 
 * This was also my conclusion, but we would like to know for sure that it
 * is the dbm package since this problem appeared within *one* week with
 * several people using completely different sizes of filesystems... I don't
 * like to maintain a timebomb that will go off some other day ... I better
 * be sure about this.

If they all mirror the RIPE DB, they will all see the problem at about
the same time. Trust me, it is dbm, Tony and I tried indexing with a
lot of other versions of dbm when we wrote the code and saw exactly
the same behaviour for the default dbm package (try indexing the
Internic database without the -p option.....)

 * I hear that most people recommend the Berkeley db package so I am
 * experimenting with that one ... (Check the perl5 man pages 'man
 * AnyDBM_File' and you know why ;-)).

Yup. Perhaps it is time to move to perl 5, that will take a bit of
rewriting though....

-Marten