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

    https://github.com/apache/spark/pull/13773#discussion_r67783068
  
    --- Diff: 
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/jdbc/JDBCRelation.scala
 ---
    @@ -52,29 +52,44 @@ private[sql] object JDBCRelation {
        * @return an array of partitions with where clause for each partition
        */
       def columnPartition(partitioning: JDBCPartitioningInfo): 
Array[Partition] = {
    -    if (partitioning == null) return Array[Partition](JDBCPartition(null, 
0))
    +    if (partitioning == null || partitioning.numPartitions <= 1 ||
    +      partitioning.lowerBound == partitioning.upperBound) {
    +      return Array[Partition](JDBCPartition(null, 0))
    +    }
     
    -    val numPartitions = partitioning.numPartitions
    -    val column = partitioning.column
    -    if (numPartitions == 1) return Array[Partition](JDBCPartition(null, 0))
    +    val lowerBound = partitioning.lowerBound
    +    val upperBound = partitioning.upperBound
    +    require (lowerBound <= upperBound,
    +      "Operation not allowed: the lower bound of partitioning column is 
larger than the upper " +
    +      s"bound. Lower bound: $lowerBound; Upper bound: $upperBound")
    +
    +    val numPartitions =
    +      if ((upperBound - lowerBound) >= partitioning.numPartitions) {
    +        partitioning.numPartitions
    +      } else {
    +        upperBound - lowerBound
    +      }
         // Overflow and silliness can happen if you subtract then divide.
         // Here we get a little roundoff, but that's (hopefully) OK.
    -    val stride: Long = (partitioning.upperBound / numPartitions
    -                      - partitioning.lowerBound / numPartitions)
    +    val stride: Long = upperBound / numPartitions - lowerBound / 
numPartitions
    +    // The automatic adjustment of numPartitions can ensure the following 
checking condition.
    +    assert(stride >= 1, "The specified number of partitions should be 
greater than " +
    --- End diff --
    
    BTW, a few years ago, I wrote codes for multi-column `column partitioning`. 
It is pretty complicated, but I am not sure if this is a good fit here. When 
the num of columns is large, the where clause could be very long. The major 
issues are the JDBC data sources might not always perform very fastly when the 
where clause is very complicated. 


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