I'm persuing this possible PostFilter solution, I can see how to collect
all the hits and recompute the scores in a PostFilter, after all the hits
have been collected (for scaling). Now, I can't see how to get the custom
doc/score values back into the main query's HitQueue. Any advice?


On Fri, Nov 29, 2013 at 9:18 AM, Peter Keegan wrote:

Instead of using a function query, could I use the edismax query (plus
some low cost filters not shown in the example) and implement the
scale/sum/product computation in a PostFilter? Is the query's maxScore
available there?


On Wed, Nov 27, 2013 at 1:58 PM, Peter Keegan wrote:

Although the 'scale' is a big part of it, here's a closer breakdown. Here
are 4 queries with increasing functions, and theei response times (caching
turned off in solrconfig):

100 msec:
select?q={!edismax v='news' qf='title^2 body'}

135 msec:
select?qq={!edismax v='news' qf='title^2
body'}q={!func}product(field(myfield),query($qq)&fq={!query v=$qq}

200 msec:
select?qq={!edismax v='news' qf='title^2

320 msec:
select?qq={!edismax v='news' qf='title^2

Btw, that no-op product is necessary, else you get this exception:

org.apache.lucene.search.BooleanQuery$BooleanWeight cannot be cast to org.apache.lucene.queries.function.valuesource.ScaleFloatFunction$ScaleInfo



On Wed, Nov 27, 2013 at 1:30 PM, Chris Hostetter <
hossman_lucene@fucit.org> wrote:
: So, this query does just what I want, but it's typically 3 times slower
: than the edismax query without the functions:

that's because the scale() function is inhernetly slow (it has to
compute the min & max value for every document in order to know how to
scale them)

what you are seeing is the price you have to pay to get that query with a
"normalized" 0-1 value.

(you might be able to save a little bit of time by eliminating that
no-Op multiply by 1: "product(query($qq),1)" ... but i doubt you'll even
notice much of a chnage given that scale function.

: Is there any way to speed this up? Would writing a custom function
: that compiled all the function queries together be any faster?

If you can find a faster implementation for scale() then by all means let
us konw, and we can fold it back into Solr.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 19 | next ›
Discussion Overview
groupsolr-user @
postedNov 7, '13 at 1:56p
activeJan 6, '14 at 6:23p



site design / logo © 2021 Grokbase