[Xapian-tickets] [Xapian] #224: Supply and optimise more OP_VALUE_ comparison operators

[Xapian]

#224: Supply and optimise more OP_VALUE_ comparison operators
---------------------+------------------------------------------------------
 Reporter:  richard  |        Owner:  olly     
     Type:  defect   |       Status:  new      
 Priority:  low      |    Milestone:  1.2.x    
Component:  Matcher  |      Version:  SVN trunk
 Severity:  minor    |   Resolution:           
 Keywords:           |    Blockedby:           
 Platform:  All      |     Blocking:           
---------------------+------------------------------------------------------
Changes (by olly):

  * milestone:  => 1.2.x


Old description:

> We currently supply OP_VALUE_GE and OP_VALUE_LE.  It might be useful to
> also
> supply OP_VALUE_GT and OP_VALUE_LT, and possibly OP_VALUE_EQ.
>
> Also, we currently supply a range operator which can be represented in
> terms of
> two comparison operators: ie, OP_VALUE_RANGE(1, a, b) is equivalent to:
> (OP_VALUE_GE(1, a) AND OP_VALUE_LE(1, b)).  It would be nice to teach the
> query
> optimiser about this equivalence, so that a range specified as two
> comparison
> operators would be transformed into an efficient single
> ValueRangePostList
> internally, instead of the combination of two Value*Cmp*PostLists.  Also,
> the
> ValueRangePostList could be made more flexible by adding flags to tell it
> whether each end of the range is inclusive or not, to allow other
> combinations
> of comparison operator to be represented as ranges.

New description:

 We currently supply OP_VALUE_GE and OP_VALUE_LE.  It might be useful to
 also
 supply OP_VALUE_GT and OP_VALUE_LT, and possibly OP_VALUE_EQ.

 Also, we currently supply a range operator which can be represented in
 terms of
 two comparison operators: ie, OP_VALUE_RANGE(1, a, b) is equivalent to:
 (OP_VALUE_GE(1, a) AND OP_VALUE_LE(1, b)).  It would be nice to teach the
 query
 optimiser about this equivalence, so that a range specified as two
 comparison
 operators would be transformed into an efficient single
 !ValueRangePostList
 internally, instead of the combination of two Value*Cmp*!PostLists.  Also,
 the
 !ValueRangePostList could be made more flexible by adding flags to tell it
 whether each end of the range is inclusive or not, to allow other
 combinations
 of comparison operator to be represented as ranges.

--

Comment:

 Implementation can easily be upwardly API and ABI compatible.

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