You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Adrien Grand (JIRA)" <ji...@apache.org> on 2014/12/22 19:12:13 UTC

[jira] [Commented] (LUCENE-6131) optimize SortingMergePolicy

    [ https://issues.apache.org/jira/browse/LUCENE-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255990#comment-14255990 ] 

Adrien Grand commented on LUCENE-6131:
--------------------------------------

+1 to adding this new boolean merging to SlowCompositeReaderWrapper
+0 to the MergeReaderWrapper approach. I think the hack is ok until we can figure a way through LUCENE-6065?

> optimize SortingMergePolicy
> ---------------------------
>
>                 Key: LUCENE-6131
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6131
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>         Attachments: LUCENE-6131.patch
>
>
> This has a number of performance problems today:
> # suboptimal stored fields merging. This is especially the case with high compression. Today this is 7x-64x times slower than it should be.
> # ram stacking: for any docvalues and norms fields, all instances will be loaded in RAM. for any string docvalues fields, all instances of global ordinals will be built, and none of this released until the whole merge is complete.
> We can fix these two problems without completely refactoring LeafReader... we won't get a "bulk byte merge", checksum computation will still be suboptimal, and its not a general solution to "merging with filterreaders" but that stuff can be for another day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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