Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Importance: normal
Priority: normal
Subject: RE: Ideal Index Fragmentation
Date: Fri, 2 Sep 2005 09:31:26 -0400
Message-ID: 
 <82D2BB25EFABA3478B75FF11C88148D518D9053B@mlnyb706mb.amrs.win.ml.com>
Thread-Topic: Ideal Index Fragmentation
thread-index: AcWuSIuktcoL1pqwRUeDwefx96xSYABeSZ0Q
From: "Friedland, Zachary (EDS - Strategy)" <zachary_friedland@ml.com>
To: <java-user@lucene.apache.org>

Follow-up questions below denoted with "--"

Thanks,
Zach

-----Original Message-----
From: Erik Hatcher [mailto:erik@ehatchersolutions.com]=20
Sent: Wednesday, August 31, 2005 12:25 PM
To: java-user@lucene.apache.org
Subject: Re: Ideal Index Fragmentation


On Aug 30, 2005, at 9:53 PM, Friedland, Zachary (EDS - Strategy) wrote:
>> More assorted questions:
>>
>> *    I have been reading the posts on using Filter vs. =20
>> BooleanQuery.  To implement a search-within-a-search, it seems the =20
>> Filter is advantageous due to its cacheability, but are there other =20
>> pros or cons that should be considered (memory, speed, etc).

>It's only advantageous when the Filters are long-lived over multiple =20
>searches.  It's not really recommended for search-within-search when =20
>the initial search is transient.  Combining queries within a =20
>BooleanQuery is more recommended in that case.

--Great!  This one is closed down...

>> *    I'm interested in implementing a "dynamic filter" component =20
>> that will walk through the hits[] object and pull out distinct =20
>> values for certain fields to display as search-within-a-search =20
>> options (all of them will return at least one result since they are =20
>> in the hits[]).  Has anyone implemented something like this -- how =20
>> did it work out?

>Walking all Hits and extracting a field is an expensive operation, so =20
>be forewarned on that.

--OK, is there a preferred strategy for generating lists of distinct
attributes in the hit[]?  I've seen Hoss' post about using QueryFilters,
but that assumes that you know what values you want to count; but I
won't know the domain of values to expect in every field...  Can I get
creative with the hitsCollector to solve this one?

>> *    When using a ParallelMultiSearcher, is there an easy way to =20
>> know how many matches came from each index searched?  I'd like to =20
>> be able to display how many of each object are in the combined hits=20
>> [].  Since I'm storing one object type per index, the count of hits =20
>> from each index will give me that number.

>I'm not sure if you can get at each indexes results in that way, but =20
>you can tell which index an individual hit came from (see API docs =20
>for details on that).

--Has anyone else hacked the ParallelMultisearcher to do something like
a hits.length before recombining them?

>> *    Does anyone know when 1.9/2.0 will be released?

>Your guess is as good as any at this point.  I'm not sure what is =20
>still left to be done for a 1.9 release.  I haven't heard any prods =20
>to release it any time soon, but you're welcome to push us to =20
>consider it if need be.

>     Erik


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

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

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