Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 81121 invoked from network); 29 Jun 2010 13:51:00 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Jun 2010 13:51:00 -0000 Received: (qmail 62867 invoked by uid 500); 29 Jun 2010 13:50:59 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 62665 invoked by uid 500); 29 Jun 2010 13:50:56 -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 62654 invoked by uid 99); 29 Jun 2010 13:50:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jun 2010 13:50:56 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of luke.driscoll@gmail.com designates 209.85.160.52 as permitted sender) Received: from [209.85.160.52] (HELO mail-pw0-f52.google.com) (209.85.160.52) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jun 2010 13:50:49 +0000 Received: by pwj10 with SMTP id 10so1673209pwj.11 for ; Tue, 29 Jun 2010 06:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=F51dNcPnmRKJrxAxOaIABTrl1E+DrAHzYXPAoUT9fEo=; b=TiXeHpYzyLKnzB/HhGudImbezwofoJnJdAo7/chbBOhBp5ahgfpqtm3PlMtlk4ho8J c4pnbmHMvjzmgBwzKVpnxXX4y45d2A/OAc8spZXE9zoJPDtqdVekYvitrTTb0C800Gww 0mKfiC2RsAtoL1lB2b9g02JPiNr6nL+PQm81U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=gX1z0NjDo+swME9kqEXrbHfJ64FlKvUHUmaQTaIaMF0RpOoBeJ1636LwCzc0jEKdYM ib6IM1ZxuAQWOwZd6g/JM05b7+Upp3QbsfYEFYmb1yWrdjqjzFn/3bhZkLFNLvp0GDK2 sxUp4WHXqdEAm6a8TyCXbtDVRZ0u15KXWsYA8= Received: by 10.114.90.3 with SMTP id n3mr7487606wab.149.1277819426882; Tue, 29 Jun 2010 06:50:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.125.2 with HTTP; Tue, 29 Jun 2010 06:50:06 -0700 (PDT) In-Reply-To: References: <454008.53442.qm@web31810.mail.mud.yahoo.com> From: Luke Driscoll Date: Tue, 29 Jun 2010 09:50:06 -0400 Message-ID: Subject: Re: View Efficency To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=001636b145bd06cc4f048a2b857c X-Virus-Checked: Checked by ClamAV on apache.org --001636b145bd06cc4f048a2b857c Content-Type: text/plain; charset=ISO-8859-1 One of the reasons that I have not been using couchdb-lucene is that it doesn't seem to allow us to use the reduce functionality of a view, and that the results are just the documents. Am I way off in this statement? Luke On Tue, Jun 29, 2010 at 09:38, Sebastian Cohnen < sebastiancohnen@googlemail.com> wrote: > in that case, you want the power of a search engine like lucene/solr. you > should definitely have a look at couchdb-lucene. > > You wrote in another reply: > > but we are querying through multiple document "keys" not key contents! > and we are not bios toward > > full-text indexers for now in this project. > > you can actually define very precisely what you want to have indexed by > lucene, may it be only one key, or everything down to attachments. > > > On 29.06.2010, at 15:10, Behrad Zari wrote: > > > It's AND-logic. I read my post again and found that I've written "OR" > > mistakenly. > > > > Actually talking, we are gonna filter results that are starting with > > key[i]=val[i] AND starting with key[j]=val[j] > > (our searches use startkey and endkey to filter doc ranges) > > So, we may emit compound/array keys: [key1, ...] to simulate AND-logic. > > > > I get your idea Sebastian, but CouchDB is preferred to do the actual > filtering > > (unity of all _byKey view results) since each of returned rows from the > server > > may contain huge number of results! and this is not an efficient solution > > instead of a MAY-BE-EXISTING serverside solution. (based on B+trees) > > > > --Behrad > > > > > > --001636b145bd06cc4f048a2b857c--