Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of jamie@mailarchiva.com
 designates 82.145.44.153 as permitted sender)
Message-ID: <538DA1A3.4040302@mailarchiva.com>
Date: Tue, 03 Jun 2014 12:21:23 +0200
From: Jamie <jamie@mailarchiva.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: java-user@lucene.apache.org
Subject: Re: search performance
References: <01AFE0FB733B9944974A82A09CEB7A0309C81ABB21@mail3.imedx.com>
	<01AFE0FB733B9944974A82A09CEB7A0309C835D16A@mail3.imedx.com>
	<1400581087.2420.182.camel@te-prime>
	<01AFE0FB733B9944974A82A09CEB7A0309C835D36D@mail3.imedx.com>
	<1401153243448-4138215.post@n3.nabble.com>
	<003301cf7974$7a200600$6e601200$@gmx.de>
	<01AFE0FB733B9944974A82A09CEB7A0309C881E6CF@mail3.imedx.com>
	<CAN4YXvcH=oKFmgrw2ZiGkiwOc2cq4RR1FQsq4E-Cw-nToA2Sqw@mail.gmail.com>
	<CAN4YXvf8oXwev4U8TErS3mmURwNuja6w2_PB=sxNYoKkqL2_4w@mail.gmail.com>
	<538C1F0F.3010300@mailarchiva.com>
	<CA+iSzr21AX7ZgdMHxGS7=nQqry9SupSqLjN8AFe5CZ1VJR8EfQ@mail.gmail.com>
	<538C5174.7040101@mailarchiva.com>
	<CALr4Hzr+qWTi-o2yyBp9Fz_m66oFYXEG=w9G2cT0ecxPUdv3_A@mail.gmail.com>
	<538D962E.2020809@mailarchiva.com>
	<CAPz8bx1PeKuvqgP=VqEnc2u8G9L=R_5TTJcQ5wj+VgfwBayFDw@mail.gmail.com>
	<538D99A4.1060605@mailarchiva.com>	<538D9BAC.7030501@mailarchiva.com>
 <CALr4HzpZe9AuKR6bjv4gik-m133DNV=3ONYkDUyi38V-9JXWzw@mail.gmail.com>
In-Reply-To: 
 <CALr4HzpZe9AuKR6bjv4gik-m133DNV=3ONYkDUyi38V-9JXWzw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Vitaly

See below:

On 2014/06/03, 12:09 PM, Vitaly Funstein wrote:
> A couple of questions.
>
> 1. What are you trying to achieve by setting the current thread's priority
> to max possible value? Is it grabbing as much CPU time as possible? In my
> experience, mucking with thread priorities like this is at best futile, and
> at worst quite detrimental to responsiveness and overall performance of the
> system as a whole. I would remove that line.
Yes,  you are right to be worried about this, especially since thread 
priorities behave differently on different platforms.

>
> 2. This seems suspicious:
>
> if (getPagination()) {
>                  max = start + length;
>              } else {
>                  max = getMaxResults();
>              }
>
> If start is at 100M, and length is 1000 - what do you think Lucene will try
> and do when you pass this max to the collector?
I dont see the problem here. The collector will start from zero to max 
results. I agree that from a performance perspective, ts not ideal to 
return all results from the beginning of the search, but the Lucene API 
us with no choice. I simply do not know the ScoreDoc to start from. If I 
did keep a record of it, then I would need to store all scoredocs for 
the entire result set. When there are 60M+ results, this can be 
problematic in terms of memory consumption. It would be far nicer if 
there was a searchAfter function that took a position as an integer.

Regards

Jamie
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org