From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5853 Path: main.gmane.org!not-for-mail From: David Blacka Newsgroups: gmane.emacs.gnus.general Subject: Re: nndb mailing list? Date: 04 Apr 1996 11:32:39 -0700 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146395 1583 80.91.224.250 (20 Oct 2002 20:39:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:39:55 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from biggulp.callamer.com (root@biggulp.callamer.com [199.74.141.2]) by deanna.miranova.com (8.7.5/8.6.9) with ESMTP id LAA00373 for ; Thu, 4 Apr 1996 11:06:08 -0800 Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by biggulp.callamer.com (8.7.4/8.7.3) with SMTP id KAA23175 for ; Thu, 4 Apr 1996 10:52:43 -0800 (PST) Original-Received: from arlh012.den.mmc.com (arlh012.den.mmc.com [160.205.18.17]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 4 Apr 1996 20:28:33 +0200 Original-Received: by arlh012.den.mmc.com (1.37.109.15/16.2) id AA194242760; Thu, 4 Apr 1996 11:32:40 -0700 Original-To: ding@ifi.uio.no In-Reply-To: bmiller@cs.umn.edu's message of 03 Apr 1996 21:18:59 -0600 Original-Lines: 29 X-Mailer: September Gnus v0.61/Emacs 19.30 Xref: main.gmane.org gmane.emacs.gnus.general:5853 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5853 >>>>> "Brad" == Brad Miller writes: Brad> The GroupLens Better Bit Bureau uses gdbm as its database, and I can Brad> vouch for the fact that performance over NFS is really really bad. Brad> Also, if you happen to get into a situation where you are frequently Brad> updating the data associated with one key, the database will start to Brad> grow all out of proportion. The only solution to this seems to be to Brad> call gdbm_reorganize, but that is terribly slow. I've had some database Brad> files go from 46Meg back down to 8Meg with one call to reorg! Brad> \Brad All gdbm_reorganize actually does is just pull everthing out of the current database, and write it into a new one that replaces it. So it isn't a real speedy process, but it needs to be done to prevent the database from growing to infinite size. As far as nndb is concerned, we've found that the MH style backend is probably the best solution, both space and speed wise. While a berkely db article database is lightning fast, it is *huge*. The MH style article db is not a whole lot slower, and only sucks up inodes. The xover db (which is still some sort of db file) still can get large, though. I'm definately going to make the GDBM files reorganize occasionally. Unfortunately, there isn't an equivalent berkeley db command. -- David Blacka |dblacka@fuentez.com Software Engineer |Fuentez Systems Concepts