[
https://issues.apache.org/jira/browse/LUCENE-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850174#action_12850174
]
Toke Eskildsen commented on LUCENE-2335:
----------------------------------------
The exposed DirectoryReader is now implemented and the timing does not look
horrible. Stepping through ordered terms for a DirectoryReader to build the
structure needed for sorting is a bit faster than the sum of sorting the
individual segments. That's not quite good enough, but there is still room for
a clever read-ahead cache to make iteration more sequential at the
SegmentReader-level.
To give a ball-park figure: Something like 1 minute / 1 million terms for
segment-level sorting, which is re-used for non-changed segments on re-open.
Then something like half that time for directory-level merging, which must be
done fully at re-open.
There's no easy to use plug-in replacement yet (and it seems hard to do anyway,
as the sorter gets the readers one at a time) and the code at github is in
shambles, so no patch either. Sorry. I expect to get back to hacking in a week.
> optimization: when sorting by field, if index has one segment and field
> values are not needed, do not load String[] into field cache
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2335
> URL: https://issues.apache.org/jira/browse/LUCENE-2335
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
>
> Spinoff from java-dev thread "Sorting with little memory: A suggestion",
> started by Toke Eskildsen.
> When sorting by SortField.STRING we currently ask FieldCache for a
> StringIndex on that field.
> This can consumes tons of RAM, when the values are mostly unique (eg a title
> field), as it populates both int[] ords as well as String[] values.
> But, if the index is only one segment, and the search sets fillFields=false,
> we don't need the String[] values, just the int[] ords. If the app needs to
> show the fields it can pull them (for the 1 page) from stored fields.
> This can be a potent optimization -- alot of RAM saved -- for optimized
> indexes.
> When fixing this we must take care to share the int[] ords if some queries do
> fillFields=true and some =false... ie, FieldCache will be called twice and it
> should share the int[] ords across those invocations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
