quickstep-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From shixuan-fan <...@git.apache.org>
Subject [GitHub] incubator-quickstep pull request #45: QUICKSTEP-20: PhysicalGenerator suppor...
Date Tue, 28 Jun 2016 21:41:03 GMT
Github user shixuan-fan commented on a diff in the pull request:

    https://github.com/apache/incubator-quickstep/pull/45#discussion_r68849181
  
    --- Diff: query_optimizer/ExecutionGenerator.cpp ---
    @@ -1575,21 +1579,12 @@ void ExecutionGenerator::convertSort(const P::SortPtr &physical_sort)
{
       merged_runs_destination_proto->set_relational_op_index(merge_run_operator_index);
       sorted_output_destination_proto->set_relational_op_index(merge_run_operator_index);
     
    -  // Do not add merged_runs_relation into 'temporary_relation_info_vec_'
    -  // and create the DropTableOperator for it at the end. Instead, add the drop
    -  // operator right here, because the relation won't be used by any other operator.
    -  const QueryPlan::DAGNodeIndex drop_merged_runs_index =
    -      execution_plan_->addRelationalOperator(
    -          new DropTableOperator(
    -              query_handle_->query_id(),
    -              *merged_runs_relation,
    -              optimizer_context_->catalog_database(),
    -              false /* only_drop_blocks */));
    -  execution_plan_->addDirectDependency(
    -      drop_merged_runs_index,
    -      merge_run_operator_index,
    -      true /* is_pipeline_breaker */);
    -
    +  // REVIEW(Shixuan): There might be an issue with the original code: if a throw
    +  // happens before the plan is executed, merged_runs_relation will not be dropped
    +  // by dropAllTemporaryRelations() if not added to temporary_relation_info_vec,
    +  // which might cause "RelationNameCollision".
    +  temporary_relation_info_vec_.emplace_back(merge_run_operator_index,
    --- End diff --
    
    In the `window aggregation`, the window aggregation operator will be placed after the
sort operator, that is, it will do the actual calculation after the table is sorted. So the
work flow would be:
    
    input_table -> sort -> window_aggregation -> output.
    
    In my current implementation, there will be an exception at the physical node with `kWindowAggregate`
type, which is preceded by a sort operator, and that's why `RelationNameCollision` happened.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message