Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 70540 invoked from network); 1 Mar 2010 07:42:50 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Mar 2010 07:42:50 -0000 Received: (qmail 29856 invoked by uid 500); 28 Feb 2010 15:42:49 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 29828 invoked by uid 500); 28 Feb 2010 15:42:49 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 29804 invoked by uid 99); 28 Feb 2010 15:42:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 15:42:49 +0000 X-ASF-Spam-Status: No, hits=3.7 required=10.0 tests=HTML_MESSAGE,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fdmanana@gmail.com designates 209.85.220.209 as permitted sender) Received: from [209.85.220.209] (HELO mail-fx0-f209.google.com) (209.85.220.209) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 15:42:42 +0000 Received: by fxm1 with SMTP id 1so1639048fxm.35 for ; Sun, 28 Feb 2010 07:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=gRfRl6xjh/HOYrEPvFCupzgh9fudwHxazAIn2s94MNo=; b=gylWoKHcieLBpZUHalyFWjIcEUQ6UoM7L17Kw2REFo0jh+WALMJVwPzqs95oGn7+eJ u8fFfDDKzZQ3UlPXMKWVsEYh36yB3quZG1fzr7reWYws53pjUIYWP32aaJgMhtfYbVuP 2gn1vAqqkDlyk0F+yZ3AyCn8NuK4Bc9PyzGjs= 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; b=EKu3P1gl0wS45F4qb+yzMflsb4T6iUExCb9+rYGVrkyghJE8M3W9qU6hRqCTNYxUcv j/moUxwvP62V/q+jEQS/4RRCpA+/hAvfkOI8RhIdBgXIM/C1mOJLTGL813QgPGZjX2sw F91yf3Tw95VF0djehJh/X3lvuYz1wSwNkcph8= MIME-Version: 1.0 Received: by 10.239.169.20 with SMTP id m20mr313535hbe.20.1267371740338; Sun, 28 Feb 2010 07:42:20 -0800 (PST) Reply-To: fdmanana@gmail.com In-Reply-To: <7C5AB910-A94E-411A-8D81-0E5C33F28FEB@gmail.com> References: <7C5AB910-A94E-411A-8D81-0E5C33F28FEB@gmail.com> Date: Sun, 28 Feb 2010 16:42:20 +0100 Message-ID: Subject: Re: /_all_dbs and security From: Filipe David Manana To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=001636498e83619bbd0480aafabb --001636498e83619bbd0480aafabb Content-Type: text/plain; charset=UTF-8 > this is the best reason I've heard for making it a security document. I > wonder how much slower the 7.5k dbs scan proceeds when it has to look up > documents instead of linked objects? do you mind adding a doc-read to the > tight loop just to see what it does to performance? > $ time curl http://localhost:5984/_all_dbs | wc -l % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 100k 0 100k 0 0 576 0 --:--:-- 0:02:57 --:--:-- 555 7397 real 2m57.811s user 0m0.000s sys 0m0.020s Alot more as expected. > > the 7.5k thing isn't important once we have a _dbs db, but the cost it will > expose as a benchmark will be proportional to the cost incurred on opening > any db for any operation, and thus significant. > True. Traversing the b-tree of _dbs to find if a particular doc exists, and then eventually insert it (which could imply re-balancing the tree from time to time) would take several disk accesses. Any other ideas on how to implement _all_dbs efficiently? cheers -- Filipe David Manana, fdmanana@gmail.com PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." --001636498e83619bbd0480aafabb--