From users-return-13833-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Dec 18 08:58:34 2009 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 7540 invoked from network); 18 Dec 2009 08:58:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 18 Dec 2009 08:58:34 -0000 Received: (qmail 2886 invoked by uid 500); 18 Dec 2009 08:58:33 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 2821 invoked by uid 500); 18 Dec 2009 08:58:32 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 2810 invoked by uid 99); 18 Dec 2009 08:58:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Dec 2009 08:58:32 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.18.2.177] (HELO exprod7og112.obsmtp.com) (64.18.2.177) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 18 Dec 2009 08:58:23 +0000 Received: from source ([209.85.160.53]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSytEGRpasFgAZv6Ks8tngU+k8gTrO/3o@postini.com; Fri, 18 Dec 2009 00:58:02 PST Received: by pwi18 with SMTP id 18so6471116pwi.32 for ; Fri, 18 Dec 2009 00:57:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.56.8 with SMTP id e8mr2549958rva.175.1261126679660; Fri, 18 Dec 2009 00:57:59 -0800 (PST) In-Reply-To: <4B2A99A2.1020409@rug.nl> References: <4B177B0F.8040303@rug.nl> <697f8380912030104wb5e2d51xd8708b7c2de4a15@mail.gmail.com> <4B221DF9.5050200@rug.nl> <697f8380912131405o3914fe0ay728902eb03475199@mail.gmail.com> <4B2A99A2.1020409@rug.nl> Date: Fri, 18 Dec 2009 09:57:59 +0100 Message-ID: <697f8380912180057u1aaa32cm94cf2bc5409d842f@mail.gmail.com> Subject: Re: Searching for a property From: Ard Schrijvers To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hello Dennis, On Thu, Dec 17, 2009 at 9:50 PM, Dennis van der Laan wrote: > > Could this mean that there is not enough memory for the Lucene indexes > and the indexes are read from disk all the time? The problem is not Lucene: if Lucene is slow, the problem is in *how* Lucene is used. > Any idea how large the indexes will become? I have no idea how the Depends on the size of your repository. We have sizes of around 20 Gb. Depending on what your queries are, you are fine > internals of Lucene look like. The virtual paths have an average string > length of about 50 characters and we end up having about 1 million of > these properties. Depending, again, on how you query this will lead to large memory consumptions. If you sort on it for example. Internally in Lucene a lot of memory is taken for it, and in Jackrabbit again. So, 50 chars, 4 byte a char (?) * 10^6 * 2 = 400 Mb... > > Thanks for any help! See next mail :-)) Regards Ard > > Dennis >> >>> A related question: could it be that when a query returns no results, >>> this is slower than when it does return a result? Might it have >>> something to do with Lucene not having an index for that particular >>> property value? >>> >> >> No, an inverted index structure does not suffer from this >> >> Regards Ard >> >> >>>> Hello Dennis, >>>> >>>> > >