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

    https://github.com/apache/spark/pull/17148#discussion_r104290248
  
    --- Diff: 
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/plans/logical/statsEstimation/FilterEstimation.scala
 ---
    @@ -101,21 +101,23 @@ case class FilterEstimation(plan: Filter, 
catalystConf: CatalystConf) extends Lo
             }
     
           case Or(cond1, cond2) =>
    -        // For ease of debugging, we compute percent1 and percent2 in 2 
statements.
             val percent1 = calculateFilterSelectivity(cond1, update = false)
             val percent2 = calculateFilterSelectivity(cond2, update = false)
             (percent1, percent2) match {
               case (Some(p1), Some(p2)) => Some(math.min(1.0, p1 + p2 - (p1 * 
p2)))
    -          case (Some(p1), None) => Some(1.0)
    -          case (None, Some(p2)) => Some(1.0)
    -          case (None, None) => None
    +          case _ => None
             }
     
    -      case Not(cond) => calculateFilterSelectivity(cond, update = false) 
match {
    -        case Some(percent) => Some(1.0 - percent)
    -        // for not-supported condition, set filter selectivity to a 
conservative estimate 100%
    -        case None => None
    -      }
    +      case Not(cond) =>
    +        if (cond.isInstanceOf[And] || cond.isInstanceOf[Or]) {
    +          // Don't support compound Not expression.
    --- End diff --
    
    If we over-estimate for a condition `cond1` in `calculateSingleCondition`, 
then `Not(cond1)` becomes under-estimation, even if `cond1` is not a compound 
condition.
    
    Actually I'm thinking whether it's reasonable to differentiate between 
under-estimation and over-estimation. Since we assume uniform distribution, we 
really can't be sure if we are over-estimating or not.
    
    E.g. for condition `a=1`, we estimate filter factor as `1/ndv`, it can be 
over-estimation if `1` is a value in the "long tail", or be under-estimation if 
`1` is the skew value of this column.
    In fact, what we do now is just using some empirical formula to compute the 
probability that the condition satisfies.
    
    So I suggest that we don't care about "nested Not" or "Not", just do what 
we do for other compound conditions as before:
    ```
        case Not(cond) =>
          calculateFilterSelectivity(cond, update = false) match {
            case Some(percent) => Some(1.0 - percent)
            case None => None
          }
    ```
    What do you think? @cloud-fan @ron8hu 


---
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 [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to