[
https://issues.apache.org/jira/browse/LUCENE-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15558552#comment-15558552
]
Michael McCandless commented on LUCENE-7283:
--------------------------------------------
bq. I imagine they will be quite surprised to see everything about the
FieldCache removed and left with no ability to Sort on an indexed-only field.
I doubt that.
In ancient Lucene versions, sorting was not a "first class citizen" and hacks
like field cache were necessary.
But then, long ago, we added doc values, and we've been saying for years now
that if you want to sort by X you need to index X as doc values. This change
(in 7.0 only, just deprecated in 6.x) should come as a surprise to nobody.
Doc values are far more efficient than the the legacy field cache: no up front
penalty the first time you sort on the field, no massive heap usage, no heavy
full GC cost. Instead the OS manages the hot pages and swaps as necessary,
thanks to efficient doc values codec formats.
And such theoretical users have plenty of options: they can use Solr, or only
use {{UninvertingReader}} or {{SlowCompositeReaderWrapper}} out of Solr's
sources, or fork them for their own purposes, or reindex with the
much-more-efficient doc values.
Such horribly inefficient legacy code really does not belong in Lucene (or
Solr!).
> Move SlowCompositeReaderWrapper and uninverting package to solr sources
> -----------------------------------------------------------------------
>
> Key: LUCENE-7283
> URL: https://issues.apache.org/jira/browse/LUCENE-7283
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7283.patch
>
>
> Spinoff from LUCENE-6766, where we fixed index-time sorting to have first
> class support in Lucene's ore, and no longer use
> {{SlowCompositeReaderWrapper}}.
> This is a dangerous, long living class, that tries to pretend a set of N
> segments is actually just a single segment. It's a leaky abstraction, has
> poor performance, and puts undue pressure on the APIs of new Lucene features
> to try to keep up this illusion.
> With LUCENE-6766, finally all usage of this class (except for
> {{UninvertedReader}} tests, which should maybe also move out?) has been
> removed from Lucene, so I think we should move it to Solr. This may also
> lead to a solution for LUCENE-7086 since e.g. the class could tap into solr's
> schema to "know" how to handle points fields properly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
