lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [jira] [Commented] (SOLR-4656) Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting
Date Mon, 03 Nov 2014 19:33:33 GMT


Erick Erickson commented on SOLR-4656:


bq:  Shouldn't the field value lengths be accumulated,
I see where you're going, and I have I admit I didn't originate this code so all things are
It's a little different sense than maxAnayzedChars in that the unit of measurement is the
number of MV entries rather than the number of characters analyzed, but I could argue either

bq:  shouldn't this field value loop exit early once ...
I have no objection.

Although it sees kind of late to take away this parameter, should we deprecate it insteas?

> Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while
> -----------------------------------------------------------------------------------------------------
>                 Key: SOLR-4656
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: highlighter
>    Affects Versions: 4.3, Trunk
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Minor
>             Fix For: 4.3, Trunk
>         Attachments: SOLR-4656-4x.patch, SOLR-4656-4x.patch, SOLR-4656-trunk.patch, SOLR-4656.patch
> I'm looking at an admittedly pathological case of many, many entries in a multiValued
field, and trying to implement a way to limit the number examined, analogous to maxAnalyzedChars,
see the patch.
> Along the way, I noticed that we do what looks like unnecessary copying of the fields
to be examined. We call Document.getFields, which copies all of the fields and values to the
returned array. Then we copy all of those to another array, converting them to Strings. Then
we actually examine them. a> this doesn't seem very efficient and b> reduces the benefit
from limiting the number of mv values examined.
> So the attached does two things:
> 1> attempts to fix this
> 2> implements hl.maxMultiValuedToExamine
> I'd _really_ love it if someone who knows the highlighting code takes a peek at the fix
to see if I've messed things up, the changes are actually pretty minimal.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message