[Xapian-tickets] [Xapian] #378: Optimise MultiAndPostList using current weight of lhs

[Xapian]

#378: Optimise MultiAndPostList using current weight of lhs
-------------------------+--------------------------------------------------
 Reporter:  richard      |       Owner:  richard  
     Type:  enhancement  |      Status:  assigned 
 Priority:  normal       |   Milestone:  1.1.2    
Component:  Matcher      |     Version:  SVN trunk
 Severity:  normal       |    Keywords:           
Blockedby:               |    Platform:  All      
 Blocking:               |  
-------------------------+--------------------------------------------------

Comment(by richard):

 In the short term, I'd feel fairly comfortable about applying the patch;
 though there are definitely cases in which it will reduce performance, the
 gain in other cases is quite significant.  I'm not desperate for it to be
 applied, though, since in most of the situations I found little change in
 performance.  The uncertainty is probably a good argument for leaving it
 as it is.

 I think that we're reaching the limit of what can be done with matcher
 optimisations without giving the matcher extra information (such as
 estimated "costs" for each postlist, as suggested above).  If and when we
 add such things, it should be more obvious which path to take.

 The other option is to make a public option on the matcher to select which
 path to try.  Users desperate for low-latency search results, but with
 plenty of CPU to spare, could then try running the search in parallel
 using each path, and discard whichever path doesn't complete first.

-- 
Ticket URL: <http://trac.xapian.org/ticket/378#comment:5>
Xapian <http://xapian.org/>
Xapian