Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 58901 invoked from network); 7 Nov 2010 17:02:23 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 7 Nov 2010 17:02:23 -0000 Received: (qmail 82572 invoked by uid 500); 7 Nov 2010 17:02:52 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 82412 invoked by uid 500); 7 Nov 2010 17:02:51 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 82404 invoked by uid 99); 7 Nov 2010 17:02:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Nov 2010 17:02:51 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sivang@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-iw0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Nov 2010 17:02:46 +0000 Received: by iwn37 with SMTP id 37so5276567iwn.11 for ; Sun, 07 Nov 2010 09:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=en5Y/Mjau/I5IMq11kz3KWLhfWwufLTPxncpkz1tB3U=; b=GLFspNtbev4Cpm7PnhbIKx8xQjNyMgJstL7CCfKBhikicmtSDlBZlNm03Le8hoCwTV Jwq4oxtnOZ/2bUemXz+yu2bPspfknBZDgS20OXdrgeTTB8bvOrANhYWpcb0KVLBt1Luk J8tjI0OFoMs5pePKuDv/+YeWLBVjL9dsehdmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=NZSxJGx9UnVDYvSqxxcY+x/+GonBVTT7uKTieGp7mL7Bq1co1vaO+ukBug9rH/TAjt CFMlj73mHMmw+d62qY3LJXFbSgxaHom+QYqmSrMWkeJ9YVGdxK8S+5iH68zw5HBEMqoX yV1ZVVVFikEDLRGg9js0Nff0f1i3WGrO9n7T4= MIME-Version: 1.0 Received: by 10.42.179.1 with SMTP id bo1mr513946icb.233.1289149345915; Sun, 07 Nov 2010 09:02:25 -0800 (PST) Received: by 10.231.173.69 with HTTP; Sun, 7 Nov 2010 09:02:25 -0800 (PST) Reply-To: sivan@omniqueue.com In-Reply-To: References: Date: Sun, 7 Nov 2010 19:02:25 +0200 Message-ID: Subject: Fwd: Questions about database file sizes. From: Sivan Greenberg To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Sivan Greenberg Date: Sun, Nov 7, 2010 at 6:58 PM Subject: Questions about database file sizes. To: users@couchdb.apache.org Hi List, =A0First I'd like to say that my longly developed couchdb based system seems to be performing well and serving its purpose. =A0However, there's always a small difference between the database files on the 2 couchdb server nodes we are using, after identical compaction steps on both db's, the difference remains around 4k, even though the number of documents is the same. =A0This is CouchDB 0.11.0 , 2 nodes, each one does a pull replication from its peer in continue replication over HTTP. =A0Is this normal? Can we sleep at night without fearing the delta would at some edge case occasion increase to the gigs ? Is it unrealistic to expect the two files to be of the same size given same compaction steps were taken and they both replicate pull from each other? Many thanks, (CouchDB Rocks!) -Sivan