Relax type incompatibility in order by clause (impl. dep. instead of XPST0004)

[ghislainfourny]

In the case where XQuery is used with very large sequences (billions/trillions of items or of tuples) with a parallel evaluation [1], the order by clause in its current state is costly to evaluate, because checking the primitive types for compatibility requires an extra step and materialization (in the case of Spark: an additional action to perform this check).

Relaxing this by making the order between different primitive types implementation-dependent (for the purpose of order by) rather than throwing XPST0004, in case of several incompatible primitive types in the comparison keys, would make parallel implementations more efficient.

[1] http://www.vldb.org/pvldb/vol14/p498-muller.pdf

[michaelhkay]

Presumably this rule also causes problems:

If each value is an instance of one of the types xs:decimal or xs:float, then all values are cast to type xs:float.

Because you don't know how to compare two decimals until you know whether the sequence also contains an xs:float and/or an xs:double.

With the new rules for numeric "lt", I think we can change that.

I'd like to avoid any further divergence between XQuery order by, XPath fn:sort(), and XSLT xsl:sort

[ghislainfourny]

Indeed, this rule also jointly contributes to the problem. The extra materialization step is also needed because of it. The output of this extra step is the overall type to use (or an error), and then sorting happens in another round by casting everything to that overall type.

[ChristianGruen]

Has the problem been mitigated by #866/#881?
If yes, should we close the issue?

[ndw]

The CG agreed to close this issue without action at meeting 065