Skip to content

Commit 8864374

Browse files
committed
lint
1 parent cbfb904 commit 8864374

File tree

1 file changed

+8
-8
lines changed
  • datafusion/expr/src/logical_plan

1 file changed

+8
-8
lines changed

datafusion/expr/src/logical_plan/plan.rs

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -2609,25 +2609,25 @@ impl PartialOrd for Window {
26092609
}
26102610

26112611
/// Communicates the desired ordering of the output of a scan operation.
2612-
///
2612+
///
26132613
/// Preferred orderings can potentially help DataFusion optimize queries, even in cases
2614-
/// when the output does not completely follow that order. This is information passed
2614+
/// when the output does not completely follow that order. This is information passed
26152615
/// to the scan about what might help.
2616-
///
2616+
///
26172617
/// For example, a query with `ORDER BY time DESC LIMIT 10`, DataFusion's dynamic
26182618
/// predicates and TopK operator will work better if the data is roughly ordered by descending
26192619
/// time (more recent data first).
2620-
///
2620+
///
26212621
/// Implementers of [`TableProvider`] should use this information to optimize the order in which data is output from the scan.
2622-
///
2622+
///
26232623
/// It is a hint and not a requirement:
26242624
/// - If this information is completely ignored, e.g. data is scanned randomly, the query will still be correct because a sort will be applied to the data.
26252625
/// - Partially ordered data will also be re-sorted but this may result in optimizations like early stopping, additional data pruning, reduced memory usage during the sort, etc.
26262626
/// - If the scan produces exactly the requested ordering, and sets it's properties to reflect this, upstream sorts may be optimized away.
2627-
///
2628-
/// Actually removing unecessary sorts is done at the physical plan level: logical operators like a join may or may not preserve ordering
2627+
///
2628+
/// Actually removing unnecessary sorts is done at the physical plan level: logical operators like a join may or may not preserve ordering
26292629
/// depending on what physical operator is chosen (e.g. HashJoin vs. SortMergeJoin).
2630-
/// If you as a [`TableProvider`] implementer would like to eliminiate unecessary sorts you shuold make sure the [`ExecutionPlan`]
2630+
/// If you as a [`TableProvider`] implementer would like to eliminiate unnecessary sorts you should make sure the [`ExecutionPlan`]
26312631
/// you produce reflects the ordering in it's properties.
26322632
///
26332633
/// [`TableProvider`]: https://docs.rs/datafusion/latest/datafusion/catalog/trait.TableProvider.html

0 commit comments

Comments
 (0)