Github user wzhfy commented on a diff in the pull request:

    https://github.com/apache/spark/pull/15363#discussion_r105856838
  
    --- Diff: 
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/CostBasedJoinReorder.scala
 ---
    @@ -51,6 +51,11 @@ case class CostBasedJoinReorder(conf: CatalystConf) 
extends Rule[LogicalPlan] wi
     
       def reorder(plan: LogicalPlan, output: AttributeSet): LogicalPlan = {
         val (items, conditions) = extractInnerJoins(plan)
    +    // Find the star schema joins. Currently, it returns the star join 
with the largest
    +    // fact table. In the future, it can return more than one star join 
(e.g. F1-D1-D2
    +    // and F2-D3-D4).
    +    val starJoinPlans = StarSchemaDetection(conf).findStarJoins(items, 
conditions.toSeq)
    --- End diff --
    
    The method splitting is good, let's remove this `val starJoinPlans` since 
it's not used.
    In fact I think we could first do something like this in 
`CostBasedJoinReorder`:
    ```
    if (conf.cboEnabled && conf.joinReorderEnabled) {
      do join reordering
    } else if (conf.starSchemaJoinReorder) {
      use star schema
    } else {
      plan
    }
    ```
    But since the current algorithm is in the `Operator Optimizations` batch, 
the tree structure is different from that in `CostBasedJoinReorder`, will 
moving into `CostBasedJoinReorder` break some logic in the algorithm?
    Other than that I'm fine with the current structure.


---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org

Reply via email to