[
https://issues.apache.org/jira/browse/LUCENE-6131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14256009#comment-14256009
]
Robert Muir commented on LUCENE-6131:
-------------------------------------
Exactly, i dont want to try to rush that issue or make LeafReader apis too
complicated or anything.
But at the same time we should have reasonable performance for SortingMP for
5.0, and not leave the trap where it is terribly slow.
> 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: [email protected]
For additional commands, e-mail: [email protected]
