Re: [rules-users] Order of columns and of constraints
For literal (alpha node) constraints, we test in the order they are
provided - testing stops after the first failure. For varible
constraints (beta nodes), depending on your compositeKeyDepth (1,2 or 3,
with 3 being default) we move the '==' operator(s) to the front and
index. Indexing of the first 1 to 3 == constraints means that on
propagation we do not need to test those constraints, instead we use the
index to lookup the matching facts, we then test those facts against any
remaing constraints, in the order described in the pattern. Beyond what
we already do dynamic constraint re-ordering is very difficult, as we
don't have any data to make assumptions on. In the future I guess it
should be possible to provide "training" data to help this, but we don't
have plans for this any time soon. We will however be building an
ontology language for our next release, the property constraints there
can also help us do better indexing and some level of re-ordering too.
Mark
Dirk Bergstrom wrote:
Does the order of columns in the rule definition, and the order of
constraints
within a column matter?
For a given rule, I know which test is most likely to fail, and (probably) which
one is most "expensive" in terms of processing time (eg. 'someCollection
contains $var' is more expensive than 'field == "literal"').
I'd like to put
the fail-fast tests up front, and the expensive ones last.
Does that actually work in Drools? Can I "optimize" my rules by juggling the
order of the columns and constraints?