Adress code review

Author: LiaCastaneda

datafusion/common/src/config.rs

@@ -1124,12 +1124,20 @@ config_namespace! {
         /// into the file scan phase.
         pub enable_topk_dynamic_filter_pushdown: bool, default = true
 
-        /// When set to true, uncorrelated scalar subqueries are left in
-        /// the logical plan and executed by `ScalarSubqueryExec` during physical
-        /// execution. When set to false, all scalar subqueries (including
-        /// uncorrelated ones) are rewritten to left joins by the
+        /// When set to true, uncorrelated scalar subqueries are
+        /// left in the logical plan and executed by `ScalarSubqueryExec` during
+        /// physical execution. When set to false, all scalar subqueries
+        /// (including uncorrelated ones) are rewritten to left joins by the
         /// `ScalarSubqueryToJoin` optimizer rule.
-        pub physical_uncorrelated_scalar_subquery: bool, default = true
+        ///
+        /// Note disabling this option is not recommended. It restores
+        /// pre-PR-21240 behavior, which silently produces incorrect results for
+        /// multi-row subqueries and does not support scalar subqueries in
+        /// ORDER BY / JOIN ON / aggregate-function arguments. This option is
+        /// intended as a temporary escape hatch for distributed execution
+        /// frameworks and is planned to be removed in a future DataFusion
+        /// release.
+        pub enable_physical_uncorrelated_scalar_subquery: bool, default = true
 
         /// When set to true, the optimizer will attempt to push down Join dynamic filters
         /// into the file scan phase.

datafusion/core/src/physical_planner.rs

@@ -437,15 +437,15 @@ impl DefaultPhysicalPlanner {
         session_state: &'a SessionState,
     ) -> futures::future::BoxFuture<'a, Result<Arc<dyn ExecutionPlan>>> {
         Box::pin(async move {
-            // When `physical_uncorrelated_scalar_subquery` is disabled, the
+            // When `enable_physical_uncorrelated_scalar_subquery` is disabled, the
             // `ScalarSubqueryToJoin` optimizer rule rewrites all uncorrelated
             // scalar subqueries to joins, so none should reach this point.
             // Skip collection in that case to avoid creating a no-op
             // `ScalarSubqueryExec` wrapper.
             let all_subqueries = if session_state
                 .config_options()
                 .optimizer
-                .physical_uncorrelated_scalar_subquery
+                .enable_physical_uncorrelated_scalar_subquery
             {
                 Self::collect_scalar_subqueries(logical_plan)
             } else {

datafusion/optimizer/src/scalar_subquery_to_join.rs

@@ -15,7 +15,7 @@
 // specific language governing permissions and limitations
 // under the License.
 
-//! [`ScalarSubqueryToJoin`] rewriting correlated scalar subquery filters to `JOIN`s
+//! [`ScalarSubqueryToJoin`] rewriting scalar subquery filters to `JOIN`s
 
 use std::collections::{BTreeSet, HashMap};
 use std::sync::Arc;
@@ -36,9 +36,14 @@ use datafusion_expr::logical_plan::{JoinType, Subquery};
 use datafusion_expr::utils::conjunction;
 use datafusion_expr::{Expr, LogicalPlan, LogicalPlanBuilder, lit, not, when};
 
-/// Optimizer rule that rewrites correlated scalar subquery filters to joins and
-/// places an additional projection on top of the filter, to preserve the
-/// original schema.
+/// Optimizer rule that rewrites scalar subquery filters to joins and places an
+/// additional projection on top of the filter to preserve the original schema.
+///
+/// When [`OptimizerOptions::enable_physical_uncorrelated_scalar_subquery`] is
+/// true (the default), only *correlated* scalar subqueries are rewritten here;
+/// uncorrelated ones are left for physical execution via `ScalarSubqueryExec`.
+/// When the option is false, all scalar subqueries — correlated and
+/// uncorrelated — are rewritten to left joins by this rule.
 #[derive(Default, Debug)]
 pub struct ScalarSubqueryToJoin {}
 
@@ -93,7 +98,7 @@ impl OptimizerRule for ScalarSubqueryToJoin {
                 let physical_uncorrelated = config
                     .options()
                     .optimizer
-                    .physical_uncorrelated_scalar_subquery;
+                    .enable_physical_uncorrelated_scalar_subquery;
                 // Optimization: skip the rest of the rule and its copies if
                 // there are no scalar subqueries this rule should rewrite
                 if !contains_scalar_subquery_to_rewrite(
@@ -154,7 +159,7 @@ impl OptimizerRule for ScalarSubqueryToJoin {
                 let physical_uncorrelated = config
                     .options()
                     .optimizer
-                    .physical_uncorrelated_scalar_subquery;
+                    .enable_physical_uncorrelated_scalar_subquery;
                 // Optimization: skip the rest of the rule and its copies if there
                 // are no scalar subqueries this rule should rewrite
                 if !projection.expr.iter().any(|expr| {
@@ -246,7 +251,7 @@ impl OptimizerRule for ScalarSubqueryToJoin {
 /// Returns true if the expression contains a scalar subquery that this rule
 /// should rewrite to a join.
 ///
-/// When `physical_uncorrelated_scalar_subquery` is true (the default) only
+/// When `enable_physical_uncorrelated_scalar_subquery` is true (the default) only
 /// correlated scalar subqueries are rewritten — uncorrelated ones are handled
 /// by the physical planner via `ScalarSubqueryExec`. When it is false, all
 /// scalar subqueries (correlated and uncorrelated) are rewritten.
@@ -316,9 +321,15 @@ impl TreeNodeRewriter for ExtractScalarSubQuery<'_> {
 /// where c.balance > o."avg(total)"
 /// ```
 ///
+/// When [`OptimizerOptions::enable_physical_uncorrelated_scalar_subquery`] is
+/// false, this function also handles uncorrelated scalar subqueries, rewriting
+/// them as a `Left Join: Filter: Boolean(true)` instead of leaving them for
+/// `ScalarSubqueryExec`.
+///
 /// # Arguments
 ///
-/// * `subquery` - The correlated scalar subquery to decorrelate.
+/// * `subquery` - The scalar subquery to rewrite (correlated, or uncorrelated
+///   when `enable_physical_uncorrelated_scalar_subquery` is false).
 /// * `outer_input` - The outer plan that the decorrelated subquery is
 ///   left-joined onto — the input of the `Filter` or `Projection` node
 ///   that contained the subquery.
@@ -338,7 +349,7 @@ fn build_join(
 ) -> Result<Option<(LogicalPlan, HashMap<Column, Expr>)>> {
     // `build_join` also handles uncorrelated scalar subqueries (as a left
     // join with `Boolean(true)`) when the
-    // `physical_uncorrelated_scalar_subquery` option is disabled.
+    // `enable_physical_uncorrelated_scalar_subquery` option is disabled.
     let subquery_plan = subquery.subquery.as_ref();
     let mut pull_up = PullUpCorrelatedExpr::new().with_need_handle_count_bug(true);
     let decorrelated_subquery = subquery_plan.clone().rewrite(&mut pull_up).data()?;
@@ -1205,7 +1216,9 @@ mod tests {
 
         let mut options = ConfigOptions::default();
         options.optimizer.filter_null_join_keys = true;
-        options.optimizer.physical_uncorrelated_scalar_subquery = false;
+        options
+            .optimizer
+            .enable_physical_uncorrelated_scalar_subquery = false;
         let context = crate::OptimizerContext::new_with_config_options(Arc::new(options));
 
         let rule: Arc<dyn OptimizerRule + Send + Sync> =

datafusion/sqllogictest/test_files/information_schema.slt

@@ -303,6 +303,7 @@ datafusion.optimizer.enable_distinct_aggregation_soft_limit true
 datafusion.optimizer.enable_dynamic_filter_pushdown true
 datafusion.optimizer.enable_join_dynamic_filter_pushdown true
 datafusion.optimizer.enable_leaf_expression_pushdown true
+datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery true
 datafusion.optimizer.enable_piecewise_merge_join false
 datafusion.optimizer.enable_round_robin_repartition true
 datafusion.optimizer.enable_sort_pushdown true
@@ -320,7 +321,6 @@ datafusion.optimizer.hash_join_single_partition_threshold 1048576
 datafusion.optimizer.hash_join_single_partition_threshold_rows 131072
 datafusion.optimizer.join_reordering true
 datafusion.optimizer.max_passes 3
-datafusion.optimizer.physical_uncorrelated_scalar_subquery true
 datafusion.optimizer.prefer_existing_sort false
 datafusion.optimizer.prefer_existing_union false
 datafusion.optimizer.prefer_hash_join true
@@ -454,6 +454,7 @@ datafusion.optimizer.enable_distinct_aggregation_soft_limit true When set to tru
 datafusion.optimizer.enable_dynamic_filter_pushdown true When set to true attempts to push down dynamic filters generated by operators (TopK, Join & Aggregate) into the file scan phase. For example, for a query such as `SELECT * FROM t ORDER BY timestamp DESC LIMIT 10`, the optimizer will attempt to push down the current top 10 timestamps that the TopK operator references into the file scans. This means that if we already have 10 timestamps in the year 2025 any files that only have timestamps in the year 2024 can be skipped / pruned at various stages in the scan. The config will suppress `enable_join_dynamic_filter_pushdown`, `enable_topk_dynamic_filter_pushdown` & `enable_aggregate_dynamic_filter_pushdown` So if you disable `enable_topk_dynamic_filter_pushdown`, then enable `enable_dynamic_filter_pushdown`, the `enable_topk_dynamic_filter_pushdown` will be overridden.
 datafusion.optimizer.enable_join_dynamic_filter_pushdown true When set to true, the optimizer will attempt to push down Join dynamic filters into the file scan phase.
 datafusion.optimizer.enable_leaf_expression_pushdown true When set to true, the optimizer will extract leaf expressions (such as `get_field`) from filter/sort/join nodes into projections closer to the leaf table scans, and push those projections down towards the leaf nodes.
+datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery true When set to true, uncorrelated scalar subqueries are left in the logical plan and executed by `ScalarSubqueryExec` during physical execution. When set to false, all scalar subqueries (including uncorrelated ones) are rewritten to left joins by the `ScalarSubqueryToJoin` optimizer rule. Note disabling this option is not recommended. It restores pre-PR-21240 behavior, which silently produces incorrect results for multi-row subqueries and does not support scalar subqueries in ORDER BY / JOIN ON / aggregate-function arguments. This option is intended as a temporary escape hatch for distributed execution frameworks and is planned to be removed in a future DataFusion release.
 datafusion.optimizer.enable_piecewise_merge_join false When set to true, piecewise merge join is enabled. PiecewiseMergeJoin is currently experimental. Physical planner will opt for PiecewiseMergeJoin when there is only one range filter.
 datafusion.optimizer.enable_round_robin_repartition true When set to true, the physical plan optimizer will try to add round robin repartitioning to increase parallelism to leverage more CPU cores
 datafusion.optimizer.enable_sort_pushdown true Enable sort pushdown optimization. When enabled, attempts to push sort requirements down to data sources that can natively handle them (e.g., by reversing file/row group read order). Returns **inexact ordering**: Sort operator is kept for correctness, but optimized input enables early termination for TopK queries (ORDER BY ... LIMIT N), providing significant speedup. Memory: No additional overhead (only changes read order). Future: Will add option to detect perfectly sorted data and eliminate Sort completely. Default: true
@@ -471,7 +472,6 @@ datafusion.optimizer.hash_join_single_partition_threshold 1048576 The maximum es
 datafusion.optimizer.hash_join_single_partition_threshold_rows 131072 The maximum estimated size in rows for one input side of a HashJoin will be collected into a single partition
 datafusion.optimizer.join_reordering true When set to true, the physical plan optimizer may swap join inputs based on statistics. When set to false, statistics-driven join input reordering is disabled and the original join order in the query is used.
 datafusion.optimizer.max_passes 3 Number of times that the optimizer will attempt to optimize the plan
-datafusion.optimizer.physical_uncorrelated_scalar_subquery true When set to true, uncorrelated scalar subqueries are left in the logical plan and executed by `ScalarSubqueryExec` during physical execution. When set to false, all scalar subqueries (including uncorrelated ones) are rewritten to left joins by the `ScalarSubqueryToJoin` optimizer rule.
 datafusion.optimizer.prefer_existing_sort false When true, DataFusion will opportunistically remove sorts when the data is already sorted, (i.e. setting `preserve_order` to true on `RepartitionExec`  and using `SortPreservingMergeExec`) When false, DataFusion will maximize plan parallelism using `RepartitionExec` even if this requires subsequently resorting data using a `SortExec`.
 datafusion.optimizer.prefer_existing_union false When set to true, the optimizer will not attempt to convert Union to Interleave
 datafusion.optimizer.prefer_hash_join true When set to true, the physical plan optimizer will prefer HashJoin over SortMergeJoin. HashJoin can work more efficiently than SortMergeJoin but consumes more memory

datafusion/sqllogictest/test_files/subquery.slt

@@ -2093,10 +2093,10 @@ SELECT (SELECT v FROM (SELECT 1 AS v UNION ALL SELECT 2) AS t ORDER BY v LIMIT 1
 
 #############
 ## End-to-end correctness coverage for the flag-off path.
-## When `datafusion.optimizer.physical_uncorrelated_scalar_subquery` is false,
+## When `datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery` is false,
 ## uncorrelated scalar subqueries are rewritten to left joins by
 ## `ScalarSubqueryToJoin` instead of executed by `ScalarSubqueryExec`. This
-## restores pre-PR-21240 behavior, which has three known shortcomings the
+## restores pre-PR-21240 behavior, which has two known shortcomings the
 ## physical-execution path was built to fix: multi-row subqueries silently
 ## return wrong results, and uncorrelated scalar subqueries do not work in
 ## ORDER BY / JOIN ON / aggregate-function arguments. Those cases are
@@ -2105,7 +2105,7 @@ SELECT (SELECT v FROM (SELECT 1 AS v UNION ALL SELECT 2) AS t ORDER BY v LIMIT 1
 #############
 
 statement ok
-set datafusion.optimizer.physical_uncorrelated_scalar_subquery = false;
+set datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery = false;
 
 # Scalar subquery returning exactly one row → success
 query I
@@ -2178,7 +2178,7 @@ SELECT 1 = (SELECT CAST(NULL AS INT));
 NULL
 
 statement ok
-RESET datafusion.optimizer.physical_uncorrelated_scalar_subquery;
+RESET datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery;
 
 statement count 0
 DROP TABLE sq_values;

datafusion/sqllogictest/test_files/tpch/tpch.slt

@@ -23,12 +23,12 @@ include ./answers/q*.slt.part
 
 # test answers with uncorrelated scalar subqueries rewritten to joins
 statement ok
-set datafusion.optimizer.physical_uncorrelated_scalar_subquery = false;
+set datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery = false;
 
 include ./answers/q*.slt.part
 
 statement ok
-reset datafusion.optimizer.physical_uncorrelated_scalar_subquery;
+reset datafusion.optimizer.enable_physical_uncorrelated_scalar_subquery;
 
 # test answers with sort merge join
 statement ok