[
https://issues.apache.org/jira/browse/SOLR-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621055#comment-16621055
]
David Smiley commented on SOLR-12782:
-------------------------------------
The UninvertingReader adds extremely little overhead so it's not really a big
deal to avoid wrapping another reader. Another possibility is to make building
the FieldInfos lazy on the first call to UninvertingReader.getFieldInfos(). In
this circumstance, it'd always wrap (though I still like the static wrap
method). However, the main user of this, SolrIndexSearcher, wraps a
SolrCompositeReaderWrapper around the reader (which will contain
UninvertingReader), and SCRW eagerly grabs the FieldInfos via
MultiFields.getFields/LeafReaderFields. Shrug.
I was also looking at IndexSchema.getUninversionMap(reader):Map. It's a shame
to see this method call MultiFields.getMergedFieldInfos(reader) and do all this
looping. It might not be heavy but nonetheless it seems unnecessary. I think
we don't need this method as it's largely redundant with checking that
UninvertingReader does already or nearly does with slightly more conditions.
All we need is a simple mapping of field name to Uninverting.Type. This could
be done with a lambda and needn't insist on a Map. I'm trying this out and
so-far-so good.
> UninvertingReader can be avoided if there are no fields to uninvert
> -------------------------------------------------------------------
>
> Key: SOLR-12782
> URL: https://issues.apache.org/jira/browse/SOLR-12782
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Attachments: SOLR-12782.patch
>
>
> Solr uses UninvertingReader to expose DocValues on fields that don't have
> them, but do have indexed fields that can be inverted via the FieldCache. It
> has an internal constructor that takes the input LeafReader and a mapping of
> field name to UninvertingReader.Type. It builds a new FieldInfos that have
> fields reflecting DocValues. There are two things I'd like to improve here:
> # make this constructor private and instead insist you use a new wrap()
> method that has the opportunity to return the input if there is nothing to
> do. Effectively the logic today would move into this wrap method, and the
> current constructor would be dead simple, and would take the FieldInfos.
> # Do _not_ create a new {{FieldInfo}} object if the existing field is
> suitable (it's DocValuesType can stay the same). The savings here can really
> add up on machines with many indexes & segments. This is in fact what
> motivated the patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
