Actions
Bug #15
openProduct of Sum form has very poor performance.
Start date:
Due date:
% Done:
0%
Estimated time:
Resolution:
Description
[[OrderedAppend]] currently assumes that all it's operands share a common ordering. This is currently guarenteed by [[TuplesOperations]].append(), but the use of calls to project() on all operands not matching the first's variable list. This has signifigant performance ramifications as the desired ordering is unknown until any parent-join is optimised.
<br/>
<br/>
Without the projections currently done by [[TuplesOperations]].append(), we need new logic in [[OrderedAppend]] to handle mapping variables to operands columns. This is not a problem unless there the disjunction is subject to a join containing a left-bound prefix including mismatched variables.
<br/>
<br/>
Consider the following tuple expressions:
<br/>
<br/>
A[$z] ^ B( C[$z $y] v D[$y $z] )
<br/>
<br/>
Note:
<br/>
A[] will provide $z prefix to B[].
<br/>
B[] currently passes this on blindly to C[] and D[].
<br/>
This will bind $z for $y in D[], leading to an incorrect result.
<br/>
Currently the non-union compatible
<br/>
Fixing this will require either reordering D[], or filtering it; deciding between them is a performance optimisation issue.
<br/>
<br/>
A[$y $z] ^ B(C[$y] v D[$z])
<br/>
<br/>
Note:
<br/>
Here there is a full prefix provided by A[] to B[].
<br/>
The prefix needs to be decomposed for C[] and D[]
<br/>
This is a case of non-union compatible disjunction, and will probably result in UNBOUND's.
<br/>
<br/>
Cases where this is probably a problem:
<br/>
<br/>
non-symmetric sum-of-products (ie. {$a <foo> $b ^ $b <bar> $c in <m1>} v {$b <bar> $c ^ $a <foo> $b in <m2>} )
<br/>
Note: this is one of the key areas of concern. Differences between models can cause join-optimisation to generate a different ordering; This interferes with attempts to improve SOP performance which is required to support efficient views.
<br/>
<br/>
symmetric disjunctions: (ie. $s <foo> $o v $o <bar> $s). - uncommon.
<br/>
<br/>
non-union compatible disjunction (ie. $s <name> $name v $s <email> $email)
<br/>
Note: this query is better phrased as a subquery anyway.
Updated by Andrae Muys - almost 18 years ago
With the NUC-disj fixes the workaround for this bug has been implemented - the performance considerations remain. With the workaround merged to trunk this bug is downgraded from major to minor.
Updated by Andrae Muys - almost 17 years ago
- Status changed from New to In Progress
Original Topic: OrderedAppend needs to check variable orderings for arguments before passing prefix. TuplesOperations.append() needs to defer variable mapping to OrderedAppend.
Actions