quickstep-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hbdeshmukh <...@git.apache.org>
Subject [GitHub] incubator-quickstep pull request #181: Added limited optimizer support for P...
Date Tue, 07 Mar 2017 17:11:18 GMT
Github user hbdeshmukh commented on a diff in the pull request:

    https://github.com/apache/incubator-quickstep/pull/181#discussion_r104723045
  
    --- Diff: query_optimizer/ExecutionGenerator.cpp ---
    @@ -740,6 +805,202 @@ void ExecutionGenerator::convertHashJoin(const P::HashJoinPtr &physical_plan)
{
         key_types.push_back(&left_attribute_type);
       }
     
    +  const CatalogRelationInfo *build_relation_info =
    +      findRelationInfoOutputByPhysical(build_physical);
    +  const CatalogRelationInfo *probe_operator_info =
    +      findRelationInfoOutputByPhysical(probe_physical);
    +
    +  const CatalogRelation *build_relation = build_relation_info->relation;
    +  const CatalogRelation *probe_relation = probe_operator_info->relation;
    +
    +  // FIXME(quickstep-team): Add support for self-join.
    +  if (build_relation == probe_relation) {
    +    THROW_SQL_ERROR() << "Self-join is not supported";
    +  }
    +
    +  const PartitionScheme *build_partition_scheme = build_relation->getPartitionScheme();
    +  const PartitionScheme *probe_partition_scheme = probe_relation->getPartitionScheme();
    +
    +  bool build_needs_repartition = false;
    +  bool probe_needs_repartition = false;
    +  bool needs_swap = false;
    +  if (build_partition_scheme && probe_partition_scheme) {
    +    const PartitionSchemeHeader &build_partition_scheme_header = build_partition_scheme->getPartitionSchemeHeader();
    +    const PartitionSchemeHeader &probe_partition_scheme_header = probe_partition_scheme->getPartitionSchemeHeader();
    +
    +    switch (build_partition_scheme_header.getPartitionType()) {
    +      case PartitionSchemeHeader::PartitionType::kRange:
    +        build_needs_repartition = true;
    +
    +        switch (probe_partition_scheme_header.getPartitionType()) {
    +          case PartitionSchemeHeader::PartitionType::kRange:
    +            probe_needs_repartition = true;
    +            break;
    +          case PartitionSchemeHeader::PartitionType::kHash: {
    +            const attribute_id probe_partition_attr = probe_partition_scheme_header.getPartitionAttributeId();
    +            if (find(probe_attribute_ids.begin(), probe_attribute_ids.end(), probe_partition_attr)
!=
    +                    probe_attribute_ids.end()) {
    +              needs_swap = true;
    --- End diff --
    
    I am not sure if I agree. Consider the following counterexample. 
    Original build table - cardinality 10k, range partitioned. 
    Original probe table - cardinality 1M, hash partitioned. 
    
    By the above logic, you will swap the build and probe relations, thereby building a giant
hash table for 1M entries. You are going to repartition the new probe relation anyway, so
that cost isn't avoided.


---
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