Mark Miller wrote:
Michael McCandless wrote:
Today, with IndexSearcher(MultiReader), the FieldSortedHitQueue asks
FieldCache to materialize the full array for each field. Whereas
MultiSearcher only asks each child reader to materialize its array
for
the field, which is better because on r
Mark Miller wrote:
MultiSearcher has a few aspects I don't like.
Do you mean the score differences vs IndexSearcher(MultiReader), or
is there something else?
And rewrite does not work properly. And to get 30 docs over 3
indexes, you ask for 90. And sort twice.
I'm thinking we stick wi
> >>> MultiSearcher has a few aspects I don't like.
> >>
> >> Do you mean the score differences vs IndexSearcher(MultiReader), or
> >> is there something else?
> > And rewrite does not work properly. And to get 30 docs over 3
> > indexes, you ask for 90. And sort twice.
>
> I'm thinking we stick w
Michael McCandless wrote:
I'd like to decouple "upgraded to Object" vs "materialize full array",
ie, so we can access native values w/o materializing the full array.
I also think "upgrade to Object" is dangerous to even offer since it's
so costly.
I'm right with you. I didn't think the Ob
[
https://issues.apache.org/jira/browse/LUCENE-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1481:
--
Attachment: LUCENE-1481.patch
Attached the patch that extends Sort and SortField by a hashCode
[
https://issues.apache.org/jira/browse/LUCENE-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1481:
--
Lucene Fields: [New, Patch Available] (was: [New])
> Sort and SortField does not have equals(
[
https://issues.apache.org/jira/browse/LUCENE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1478:
--
Attachment: LUCENE-1478.patch
New patch that integrates Mike's comments. This version still us
One thing to keep in mind about using the field cache for filter
caching.
The filter bitset cache at worst holds 8 documents per byte (and with
bitset compression this can be even more efficient).
Using the field cache is going to rather be bytes per document, most
likely at least an orde
Hallo Robert,
> This is why I think for many users the field cache is not the best
> solution. If you have lots of documents but searchers that return
> relatively few, then using filters and sorting the results using
> stored fields is far more efficient.
>
> It seems to me that the field cache
[
https://issues.apache.org/jira/browse/LUCENE-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654258#action_12654258
]
Mark Miller commented on LUCENE-1026:
-
Anyone use this? I think its convenient myself,
[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654269#action_12654269
]
Marvin Humphrey commented on LUCENE-1476:
-
> One approach would be to use a "segme
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/669/changes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
12 matches
Mail list logo
