Bug #1929

unsorted() optimization is too aggressive

Added by Michael Kay over 4 years ago. Updated over 4 years ago.

Start date:
Due date:
% Done:


Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


In certain circumstances Saxon decides that the results of an expression can be returned in any order: examples are the argument of sum() or count() or unordered(). In this case the relevant expression is optimized to avoid unnecessary sorting. However, the optimisation is too aggressive, because it recurses to subexpressions whose order may be significant. Some paths prevent the UNORDERED optimization filtering down to subexpressions, but many paths fail to do so. For example, a FLWORExpression applies the UNORDERED optimization to each of its clauses, which may be incorrect in the case of a "for" clause with an "at" variable.


#1 Updated by Michael Kay over 4 years ago

I am testing a rather extensive patch for this whose overall effect is that the "unordered" rewrite is not propagated to subexpressions by default, but only on explicit request by the parent expression. This entails a new method on the Expression class, which is implemented for those expressions that act on unordered(). The new code is working (passes all QT3 tests) but needs to be regression tests from a performance point of view, to ensure that the rewrite is happening where it makes a significant difference. Currently it's not propagating to the clauses of a FLWORExpression.

#2 Updated by Michael Kay over 4 years ago

  • Status changed from New to Resolved

Patch now applied on both 9.5 and 9.6 branches (the 9.6 version is more comprehensive in that it deletes the old promotionOffer code which the new mechanism makes redundant).

#3 Updated by O'Neil Delpratt over 4 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to

Bug fix applied in Saxon maintenance release

Please register to edit this issue

Also available in: Atom PDF