[jira] [Updated] (DRILL-6089) Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, MaprDB, or Hive
[ https://issues.apache.org/jira/browse/DRILL-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Farkas updated DRILL-6089: -- Labels: ready-to-commit (was: ) > Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, > MaprDB, or Hive > - > > Key: DRILL-6089 > URL: https://issues.apache.org/jira/browse/DRILL-6089 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.13.0 >Reporter: Timothy Farkas >Assignee: Timothy Farkas >Priority: Major > Labels: ready-to-commit > Fix For: 1.13.0 > > > Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6089) Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, MaprDB, or Hive
[ https://issues.apache.org/jira/browse/DRILL-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Farkas updated DRILL-6089: -- Affects Version/s: 1.13.0 > Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, > MaprDB, or Hive > - > > Key: DRILL-6089 > URL: https://issues.apache.org/jira/browse/DRILL-6089 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.13.0 > Environment: Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). >Reporter: Timothy Farkas >Assignee: Timothy Farkas >Priority: Major > Fix For: 1.13.0 > > > Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6089) Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, MaprDB, or Hive
[ https://issues.apache.org/jira/browse/DRILL-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Farkas updated DRILL-6089: -- Fix Version/s: 1.13.0 > Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, > MaprDB, or Hive > - > > Key: DRILL-6089 > URL: https://issues.apache.org/jira/browse/DRILL-6089 > Project: Apache Drill > Issue Type: Improvement >Affects Versions: 1.13.0 > Environment: Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). >Reporter: Timothy Farkas >Assignee: Timothy Farkas >Priority: Major > Fix For: 1.13.0 > > > Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DRILL-6089) Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, MaprDB, or Hive
[ https://issues.apache.org/jira/browse/DRILL-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Farkas updated DRILL-6089: -- Summary: Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, MaprDB, or Hive (was: Planner changes needed as Hash-Join spill breaks left-side order) > Validate That Planner Does Not Assume HashJoin Preserves Ordering for FS, > MaprDB, or Hive > - > > Key: DRILL-6089 > URL: https://issues.apache.org/jira/browse/DRILL-6089 > Project: Apache Drill > Issue Type: Improvement > Environment: Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). >Reporter: Timothy Farkas >Assignee: Timothy Farkas >Priority: Major > > Explanation provided by Boaz: > (As explained in the design document) The new "automatic spill" feature of > the Hash-Join operator may cause (if spilling occurs) the rows from the > left/probe side to be returned in a different order than their incoming order > (due to splitting the rows into partitions). > Currently the Drill planner assumes that left-order is preserved by the > Hash-Join operator; therefore if not changes, a query relying on that order > may return wrong results (when the Hash-Join spills). > A fix is needed. Here are few options (ordered from the simpler down to the > most complex): > # Change the order rule in the planner. Thus whenever an order is needed > above (downstream) the Hash-Join, the planner would add a sort operator. That > would be a big execution time waste. > # When the planner needs the left-order above the Hash-Join, it may assess > the size of the right/build side (need statistics). If the right side is > small enough, the planner would set an option for the runtime to avoid > spilling, hence preserving the left-side order. In case spilling becomes > necessary, the code would return an error (possibly with a message suggesting > setting some special option and retrying; the special option would add a sort > operator and allow the hash-join to spill). > # When generating the code for the fragment above the Hash-Join (where > left-order should be maintained) - at code-gen time check if the hash-join > below spilled, and if so, add a sort operator. (Nothing like that exists in > Drill now, so it may be complicated). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
