imback82 commented on a change in pull request #29473:
URL: https://github.com/apache/spark/pull/29473#discussion_r478594277



##########
File path: 
sql/core/src/main/scala/org/apache/spark/sql/execution/DataSourceScanExec.scala
##########
@@ -166,15 +167,24 @@ case class FileSourceScanExec(
     requiredSchema: StructType,
     partitionFilters: Seq[Expression],
     optionalBucketSet: Option[BitSet],
-    optionalNumCoalescedBuckets: Option[Int],
+    optionalNewNumBuckets: Option[Int],
     dataFilters: Seq[Expression],
     tableIdentifier: Option[TableIdentifier])
   extends DataSourceScanExec {
 
   // Note that some vals referring the file-based relation are lazy 
intentionally
   // so that this plan can be canonicalized on executor side too. See 
SPARK-23731.
   override lazy val supportsColumnar: Boolean = {
-    relation.fileFormat.supportBatch(relation.sparkSession, schema)
+    // `RepartitioningBucketRDD` converts columnar batches to rows to 
calculate bucket id for each
+    // row, thus columnar is not supported when `RepartitioningBucketRDD` is 
used to avoid
+    // conversions from batches to rows and back to batches.
+    relation.fileFormat.supportBatch(relation.sparkSession, schema) && 
!isRepartitioningBuckets

Review comment:
       Note that the datasource will still be read as batches in this case (if 
whole stage codegen is enabled).
   
   I see that physical plans operates on rows, so batches are converted to rows 
via `ColumnarToRow` anyway. So, I think perf impact would be minimal here; the 
difference could be the code-gen conversion from columnar to row vs. iterating 
`batch.rowIterator()` in `BucketRepartitioningRDD`.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]



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

Reply via email to