Opened 12 years ago

Last modified 4 years ago

#224 new defect

Supply and optimise more OP_VALUE_ comparison operators

Reported by: richard Owned by: olly
Priority: low Milestone: 1.4.x
Component: Matcher Version: SVN trunk
Severity: minor Keywords:
Cc: Blocked By:
Blocking: Operating System: All

Description (last modified by olly)

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.

Change History (6)

comment:1 Changed 12 years ago by richard

  • Operating System set to All
  • Status changed from new to assigned

comment:2 Changed 12 years ago by olly

I think OP_VALUE_EQ would be ill-advised. If you want to find things matching an exact category, boolean terms are a lot more efficient, so OP_VALUE_EQ is just a tempting trap to disappoint users - for example:

http://article.gmane.org/gmane.comp.search.xapian.general/5481

If you really really know you want to do this (e.g. small collection, storing values for other reasons, smallest database size really matters) then you can just use OP_VALUE_RANGE with the same start and end.

comment:4 Changed 11 years ago by olly

  • Description modified (diff)
  • Owner changed from newbugs to olly
  • Status changed from assigned to new

comment:5 Changed 9 years ago by olly

  • Description modified (diff)
  • Milestone set to 1.2.x

Implementation can easily be upwardly API and ABI compatible.

comment:6 Changed 7 years ago by olly

  • Milestone changed from 1.2.x to 1.3.x

1.3.x material now, especially as the query internals have been rewritten in trunk.

comment:7 Changed 4 years ago by olly

  • Milestone changed from 1.3.x to 1.4.x

This isn't worth holding up 1.4.0 for - we haven't had user requests for such operators, and they could be added cleanly in a stable point release.

Note: See TracTickets for help on using tickets.