sunchao commented on code in PR #6938:
URL: https://github.com/apache/datafusion-comet/pull/6938#discussion_r4436269864
##########
docs/source/user-guide/latest/operators.md:
##########
@@ -102,6 +101,7 @@ omitted from the tables below and may be reconsidered based
on demand:
| `ShuffledHashJoinExec` | ✅ |
|
| `SortMergeJoinExec` | ✅ | Supports `BINARY` join keys.
Nested-type (struct, array, map) and collated-string join keys fall back to
Spark. |
| `BroadcastNestedLoopJoinExec` | ✅ | Falls back to Spark when the
preserved side is broadcast (for example LEFT OUTER with BROADCAST on the left)
([#4429](https://github.com/apache/datafusion-comet/pull/4429)). |
+| `CartesianProductExec` | ✅ | Opt-in
(`spark.comet.exec.cartesianProduct.enabled`). Only condition-free products of
single-partition inputs, such as after `COALESCE(1)`; non-bucketed scans never
qualify. |
Review Comment:
I ran a cross join on Spark 4.1.3 with one unbucketed CSV file on each side,
the native V2 CSV reader enabled, and broadcasting disabled. Each scan reported
one partition, and the executed plan contained two `CometCsvNativeScan`
children under `CometCartesianProduct`. All four row pairs were correct. Could
this row and the `CometConf` description state the actual rule: the join has no
condition and each child reports exactly one partition? That covers both CSV
and one-bucket Parquet. The legend above also gives ⚠️ to operators that
default off, which matches this flag.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
