Thanks, we tried modifying the source as suggested but found in our case PostingsHighlighter was returning no highlighting at all once we removed the self-closing tags. I think perhaps we were not using it in the correct way.
Robert Muir wrote > Do you want to open a JIRA issue to just change the behavior? Yes, I think it would be useful to have it is an optional feature which can be triggered by a parameter as suggested. This is how we implemented it, and if it were returning highlighting we would happily contribute this back, but as it stands its not properly tested. I will create a JIRA ticket to cover this desired functionality though. Robert Muir wrote > Unrelated: If your queries actually go against a large number of fields, > I'm not sure how efficient this highlighter will be. Thats because at some > number of N fields, it will be much more efficient to use a > document-oriented term vector approach (e.g. standard > highlighter/fast-vector-highlighter). Yes unfortunately it is not any faster. Our original problem was highlighting performance and in our case PostingsHighlighter is performing similarly to the default highlighter. We are now trying a solution which involves running one query to obtain the field names in the N documents retrieved (where N=rows) and then a separate query to specify those fields in 'hl.fl' parameter. This is working on the basis that those two seperate queries run much faster than one query with hl.fl=my_dynamic_field_* Thanks for your detailed responses. -- View this message in context: http://lucene.472066.n3.nabble.com/PostingsHighlighter-returning-fields-which-don-t-match-tp4084495p4084774.html Sent from the Solr - User mailing list archive at Nabble.com.
