[ https://issues.apache.org/jira/browse/LUCENE-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055580#comment-13055580 ]
Robert Muir commented on LUCENE-1889: ------------------------------------- Hi Mike, Simon has an issue open to make a lot of what you are talking about wrt positions easier: LUCENE-2878 In my opinion once LUCENE-2878 is resolved, we may want to then consider adding the capability for a codec to encode the offset deltas in parallel with the positions (so its just a stream of delta-encoded integers you read in parallel with the positions for things like highlighting). Then, highlighting would not require term vectors anymore right? I think this would be much faster and more efficient without the space waste of term vectors, and we could prototype such a thing by encoding these ourselves into the payloads... which is close to the same, but I think ultimately optionally supporting offsets this way will be better especially with block-oriented compression algorithms. > FastVectorHighlighter: support for additional queries > ----------------------------------------------------- > > Key: LUCENE-1889 > URL: https://issues.apache.org/jira/browse/LUCENE-1889 > Project: Lucene - Java > Issue Type: Wish > Components: modules/highlighter > Reporter: Robert Muir > Priority: Minor > Attachments: LUCENE-1889.patch > > > I am using fastvectorhighlighter for some strange languages and it is working > well! > One thing i noticed immediately is that many query types are not highlighted > (multitermquery, multiphrasequery, etc) > Here is one thing Michael M posted in the original ticket: > {quote} > I think a nice [eventual] model would be if we could simply re-run the > scorer on the single document (using InstantiatedIndex maybe, or > simply some sort of wrapper on the term vectors which are already a > mini-inverted-index for a single doc), but extend the scorer API to > tell us the exact term occurrences that participated in a match (which > I don't think is exposed today). > {quote} > Due to strange requirements I am using something similar to this (but > specialized to our case). > I am doing strange things like forcing multitermqueries to rewrite into > boolean queries so they will be highlighted, > and flattening multiphrasequeries into boolean or'ed phrasequeries. > I do not think these things would be 'fast', but i had a few ideas that might > help: > * looking at contrib/highlighter, you can support FilteredQuery in flatten() > by calling getQuery() right? > * maybe as a last resort, try Query.extractTerms() ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org