[
https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052409#comment-13052409
]
Paul Elschot commented on LUCENE-2454:
--------------------------------------
This overlaps with the BlockJoinQuery of LUCENE-3171, this issue might even be
closed as duplicate of that one. Which one is preferred?
On using prev/nextSetBit in a safe range, this safe range starts with the
parent and ends with the largest known child. A variant of prevSetBit could
take this largest known child as an argument to limit its search, and then from
the return value one has either a new parent, or one is certain that the
current parent is the right one. This would also limit the worst case number of
inspected bits for the group to the group size.
With or without that variant, I think it would be good to add a remark in the
javadocs about the possible inefficiency of the use of OpenBitSet for larger
group sizes. When the typical group size gets a lot bigger than the number of
bits in a long, another implementation might be faster. This remark the in
javadocs would allow us to wait for someone to come along with bigger group
sizes and a real performance problem here.
> Nested Document query support
> -----------------------------
>
> Key: LUCENE-2454
> URL: https://issues.apache.org/jira/browse/LUCENE-2454
> Project: Lucene - Java
> Issue Type: New Feature
> Components: core/search
> Affects Versions: 3.0.2
> Reporter: Mark Harwood
> Assignee: Mark Harwood
> Priority: Minor
> Attachments: LUCENE-2454.patch, LUCENE-2454.patch,
> LuceneNestedDocumentSupport.zip
>
>
> A facility for querying nested documents in a Lucene index as outlined in
> http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
