[
https://issues.apache.org/jira/browse/LUCENE-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Bowyer updated LUCENE-3917:
--------------------------------
Attachment: LUCENE-3917-Initial-port-of-index-pruning.patch
Recently at $DAYJOB the horror that is high frequency terms in OR search came
to bite us, as a result I have an interest in pruning again.
As such I made an attempt to forward port the existing pruning package directly
to Lucene 4.0.
This is largely a mechanical port, I have not put any real thought into it so
its probably terrible.
This does not pass its unit test, and is a mess internally in the code, I am
going to try to get the unit test working and then loop back on making the code
more lucene 4.x friendly.
One question that occurs from this is how AtomicReaders are handled, do we want
to pruning per segment with global stats, prune based on segment stats or just
do the terrible thing and work with a SlowCompositeReader.
I also think, given the work that went on with LUCENE-4752 it might be possible
to do the pruning in a similar fashion to the sorting merge such that we do a
pruning merge.
> Port pruning module to trunk apis
> ---------------------------------
>
> Key: LUCENE-3917
> URL: https://issues.apache.org/jira/browse/LUCENE-3917
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/other
> Affects Versions: 4.0-ALPHA
> Reporter: Robert Muir
> Fix For: 4.3
>
> Attachments: LUCENE-3917-Initial-port-of-index-pruning.patch
>
>
> Pruning module was added in LUCENE-1812, but we need to port
> this to trunk (4.0)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
