Skip to content

Commit 35c6748

Browse files
committed
Reword for clarity
1 parent 47303f6 commit 35c6748

File tree

2 files changed

+5
-5
lines changed

2 files changed

+5
-5
lines changed

datafusion/common/src/config.rs

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -454,11 +454,11 @@ config_namespace! {
454454
pub repartition_sorts: bool, default = true
455455

456456
/// When true, DataFusion will opportunistically remove sorts when the data is already sorted,
457-
/// replacing `RepartitionExec` with `SortPreservingRepartitionExec`, and
458-
/// `CoalescePartitionsExec` with `SortPreservingMergeExec`,
457+
/// (i.e. setting `preserve_order` to true on `RepartitionExec` and
458+
/// using `SortPreservingMergeExec`)
459459
///
460-
/// When false, DataFusion will prefer to maximize the parallelism using
461-
/// `Repartition/Coalesce` and resort the data subsequently with `SortExec`
460+
/// When false, DataFusion will maximize plan parallelism using
461+
/// `RepartitionExec` even if this requires subsequently resorting data using a `SortExec`.
462462
pub prefer_existing_sort: bool, default = false
463463

464464
/// When set to true, the logical plan optimizer will produce warning

docs/source/user-guide/configs.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -87,7 +87,7 @@ Environment variables are read during `SessionConfig` initialisation so they mus
8787
| datafusion.optimizer.repartition_file_scans | true | When set to `true`, file groups will be repartitioned to achieve maximum parallelism. Currently Parquet and CSV formats are supported. If set to `true`, all files will be repartitioned evenly (i.e., a single large file might be partitioned into smaller chunks) for parallel scanning. If set to `false`, different files will be read in parallel, but repartitioning won't happen within a single file. |
8888
| datafusion.optimizer.repartition_windows | true | Should DataFusion repartition data using the partitions keys to execute window functions in parallel using the provided `target_partitions` level |
8989
| datafusion.optimizer.repartition_sorts | true | Should DataFusion execute sorts in a per-partition fashion and merge afterwards instead of coalescing first and sorting globally. With this flag is enabled, plans in the form below `text "SortExec: [a@0 ASC]", " CoalescePartitionsExec", " RepartitionExec: partitioning=RoundRobinBatch(8), input_partitions=1", ` would turn into the plan below which performs better in multithreaded environments `text "SortPreservingMergeExec: [a@0 ASC]", " SortExec: [a@0 ASC]", " RepartitionExec: partitioning=RoundRobinBatch(8), input_partitions=1", ` |
90-
| datafusion.optimizer.prefer_existing_sort | false | When true, DataFusion will opportunistically remove sorts when the data is already sorted, replacing `RepartitionExec` with `SortPreservingRepartitionExec`, and `CoalescePartitionsExec` with `SortPreservingMergeExec`, When false, DataFusion will prefer to maximize the parallelism using `Repartition/Coalesce` and resort the data subsequently with `SortExec` |
90+
| 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`. |
9191
| datafusion.optimizer.skip_failed_rules | false | When set to true, the logical plan optimizer will produce warning messages if any optimization rules produce errors and then proceed to the next rule. When set to false, any rules that produce errors will cause the query to fail |
9292
| datafusion.optimizer.max_passes | 3 | Number of times that the optimizer will attempt to optimize the plan |
9393
| datafusion.optimizer.top_down_join_key_reordering | true | When set to true, the physical plan optimizer will run a top down process to reorder the join keys |

0 commit comments

Comments
 (0)