xapian-core/docs/matcherdesign.rst

   1 .. |->| unicode:: U+2192 .. right arrow
   2
   3 Matcher Design Notes
   4 ====================
   5
   6 This document is incomplete at present. It lacks explanation of the
   7 min-heap used to keep the best N M-set items (Managing Gigabytes
   8 describes this technique well), the check() method isn't discussed, and
   9 probably some other things.
  10
  11 The PostList Tree
  12 -----------------
  13
  14 The QueryOptimiser class builds a tree structure of PostList objects
  15 from the query. At the leaf level, a PostList object is created for each
  16 term, and for other leaf-level subqueries, like PostingSource objects
  17 and value ranges. Then pairs or groups of PostLists are combined using
  18 2-way or n-way branching tree elements for AND, OR, etc - these are
  19 virtual PostLists whose class names reflect the operation
  20 (MultiAndPostList, OrPostList, etc). See below for a full list.
  21
  22 OR
  23 ~~
  24
  25 For a group of OR operations, each OrPostList has two children, job).
  26 The OR tree is built up in a similar way to how an optimal huffman code
  27 is constructed, so the sub-PostLists with the fewest entries are
  28 furthest down the tree, and those with most nearest the top (this is
  29 more efficient than an n-ary tree in terms of the number of comparisons
  30 which need to be performed, ignoring various optimisations which the
  31 matcher can perform - it may actually be the case that a MultiOrPostList
  32 could do a better job in practice though).
  33
  34 OR is coded for maximum efficiency when the right branch has fewer
  35 postings in than the left branch.
  36
  37 When an OR gets "at end", it autoprunes, replacing itself with the
  38 branch that still has postings - see below for full details.
  39
  40 AND
  41 ~~~
  42
  43 For a multi-way AND operation, we have MultiAndPostList, which tries the
  44 sub-postlists in order from least frequent to most frequent (two-way AND
  45 is handled the same way). This will generally minimise the number of
  46 posting list entries we read and maximises the size of each skip\_to.
  47
  48 When one of a sub-trees of AND operations runs out, the sub-query will
  49 signal "at end", and this causes the AND to signal "at end" too.
  50
  51 The OP\_FILTER query operator is actually treated as AND in the postlist
  52 tree - the boolean-ness is pushed down to the leaf query, where it is
  53 handled by the Weight object.
  54
  55 Other operations
  56 ~~~~~~~~~~~~~~~~
  57
  58 The other operations also handle "at end" either like OR or AND (for
  59 asymmetric operations like AND\_MAYBE, which happens may depend which
  60 branch has run out).
  61
  62 running the match
  63 -----------------
  64
  65 Once the tree is built, the matcher repeatedly asks the root of the tree
  66 for the next matching document and compares it to those in the
  67 proto-mset it maintains. Once the proto-mset is of the desired final
  68 size, the candidate needs to score more highly that the lowest scoring
  69 document in the proto-mset (either by weight, or in sort order if
  70 sorting is used) to be interesting. If it is, the lowest scoring
  71 document is removed (which is easy as we store the proto-mset as a min
  72 heap) and the candidate is added.
  73
  74 When the matcher itself gets "at end" from the postlist tree, the match
  75 process ends.
  76
  77 The matcher also passes the lowest weight currently needed make the
  78 proto-mset into the tree, and each node may adjust this weight and pass
  79 it on to its subtrees. Each PostList can report a minimum weight it
  80 could contribute - so if the left branch of an AND will always return a
  81 weight of 2 or more, then if the whole AND needs to return at least 6,
  82 the right branch is told it needs to return at least 4.
  83
  84 For example, an OR knows that if its left branch can contribute at most
  85 a weight of 4 and its right branch at most 7, then if the minimum weight
  86 is 8, only documents matching both branches are now of interest so it
  87 mutates into an AND. If the minimum weight is 6 it changes into an
  88 AND\_MAYBE (A AND\_MAYBE B matches documents which which match A, but B
  89 contributes to the weight - in most search engines query syntax, that's
  90 expressed as `+A B`). See the "Operator Decay" section below for full
  91 details of these mutations. If the minimum weight needed is 12, no
  92 document is good enough, and the OR returns "end of list".
  93
  94 Phrase and near matching
  95 ------------------------
  96
  97 The way phrase and near matching works is to perform an AND query for
  98 all the terms, with a filter node in front which only returns documents
  99 whose positional information fulfils the phrase requirements.
 100
 101 Because checking the positional information can be quite costly compared
 102 to matching postlist trees, we hoist the position check higher up the
 103 tree in cases when the phrase operation is below an AND. So A AND (B
 104 NEAR C) will actually filter the results of (A AND B AND C) through a
 105 check for B NEAR C, which means we never need to check positions for
 106 documents which don't match A.
 107
 108 virtual postlist types
 109 ----------------------
 110
 111 There are several types of virtual PostList. Each type can be used in a
 112 weighted or unweighted (boolean) context - the only difference is whether the
 113 weights are used or not. The types are:
 114
 115 -  OrPostList: returns documents which match either branch
 116 -  MultiAndPostList: returns documents which match all branches
 117 -  MultiXorPostList: returns documents which match an odd number of
 118    branches
 119 -  AndNotPostList: returns documents which match the left branch, but
 120    not the right (the weights of documents from the right branch are
 121    ignored).  "X ANDNOT Y" implements what some search engines offer
 122    as "X -Y" in their query syntax.
 123 -  AndMaybePostList: returns documents which match the left branch with
 124    weights added on from the right branch where that also matches (so
 125    an unweighted AndMaybePostList isn't very useful).  "X ANDMAYBE Y"
 126    implements what some search engines offer as "+X Y" in their
 127    query syntax.
 128 -  FIXME: this list is no longer complete...
 129
 130 There are two main optimisations which the best match performs:
 131 autoprune and operator decay.
 132
 133 autoprune
 134 ---------
 135
 136 For example, if a branch in the match tree is "A OR B", when A runs out
 137 then "A OR B" is replaced by "B". Similar reductions occur for XOR,
 138 ANDNOT, and ANDMAYBE (if the right branch runs out). Other operators
 139 (AND, FILTER, and ANDMAYBE (when the left branch runs out) simply return
 140 "at\_end" and this is dealt with somewhere further up the tree as
 141 appropriate.
 142
 143 An autoprune is indicated by the next or skip\_to method returning a
 144 pointer to the PostList object to replace the postlist being read with.
 145
 146 operator decay
 147 --------------
 148
 149 The matcher tracks the minimum weight needed for a document to make it
 150 into the m-set (this decreases monotonically as the m-set forms). This
 151 can be used to replace on boolean operator with a stricter one. E.g.
 152 consider A OR B - when maxweight(A) < minweight and maxweight(B) <
 153 minweight then only documents matching both A and B can make it into the
 154 m-set so we can replace the OR with an AND. Operator decay is flagged
 155 using the same mechanism as autoprune, by returning the replacement
 156 operator from next or skip\_to.
 157
 158 Possible decays:
 159
 160 -  OR |->| AND
 161 -  OR |->| ANDMAYBE
 162 -  ANDMAYBE |->| AND
 163 -  XOR |->| ANDNOT
 164
 165 A related optimisation is that the Match object may terminate early if
 166 maxweight for the whole tree is less than the smallest weight in the
 167 mset.