Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 57130 invoked from network); 20 May 2009 11:16:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 20 May 2009 11:16:16 -0000 Received: (qmail 45290 invoked by uid 500); 20 May 2009 11:16:28 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 45259 invoked by uid 500); 20 May 2009 11:16:28 -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 45248 invoked by uid 99); 20 May 2009 11:16:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 May 2009 11:16:28 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.92.26] (HELO qw-out-2122.google.com) (74.125.92.26) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 May 2009 11:16:19 +0000 Received: by qw-out-2122.google.com with SMTP id 5so232289qwd.13 for ; Wed, 20 May 2009 04:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.82.81 with SMTP id a17mr324310qcl.107.1242818158159; Wed, 20 May 2009 04:15:58 -0700 (PDT) In-Reply-To: <23633390.post@talk.nabble.com> References: <23592190.post@talk.nabble.com> <510143ac0905180611m124e20cfta64bb9370c20a4e0@mail.gmail.com> <23633390.post@talk.nabble.com> Date: Wed, 20 May 2009 21:15:57 +1000 Message-ID: <7bd519ad0905200415nea678edw979f668237d25447@mail.gmail.com> Subject: Re: Caching/performance issue (urgent help required please!) From: Torgeir Veimo To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 2009/5/20 AdamR : > > Jukka Zitting wrote: >> >> What does the troublesome query look like? > > The queries are fairly straight forward, for example: > /jcr:root/mynode//element(*, my:nodetype) order by @myProp ascending. I then > iterate through a hundred or so nodes from the resulting NodeIterator > (which may contain many thousand results in total) and access various > properties and child nodes. Is the order by clause necessary? -- -Tor