lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3443) Port 3.x FieldCache.getDocsWithField() to trunk
Date Tue, 08 Nov 2011 15:45:51 GMT


Yonik Seeley commented on LUCENE-3443:

bq. I think we should commit this, first, then separately optimize the valid bits to single

That represents a pretty significant performance regression though, and it seems we should
try to avoid stuff like that on trunk (better in a branch if one is going to remove functionality
with the idea of adding it back later).  Or we could generate the bits by default - the extra
cache entry if not needed is less serious than doubling the generation time.

Another small piece we are losing from trunk is numUniqueTerms.
What about returning an object, so instead of getLongs() returning a long[], it would return
a LongValues that had
a long[] as well as numUniqueTerms, and docsWithValues (optionally set).  This also halves
the number of cache lookups needed when using sortMissinglast and supplies a place to put
more info in the future (stuff like numUniqueTerms).
> Port 3.x FieldCache.getDocsWithField() to trunk
> -----------------------------------------------
>                 Key: LUCENE-3443
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 3.5, 4.0
>         Attachments: LUCENE-3443.patch
> [Spinoff from LUCENE-3390]
> I think the approach in 3.x for handling un-valued docs, and making it
> possible to specify how such docs are sorted, is better than the
> solution we have in trunk.
> I like that FC has a dedicated method to get the Bits for docs with field
> -- easy for apps to directly use.  And I like that the
> bits have their own entry in the FC.
> One downside is that it's 2 passes to get values and valid bits, but
> I think we can fix this by passing optional bool to FC.getXXX methods
> indicating you want the bits, and the populate the FC entry for the
> missing bits as well.  (We can do that for 3.x and trunk). Then it's
> single pass.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message