You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: datafusion/expr/src/logical_plan/plan.rs
+8-8Lines changed: 8 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -2609,25 +2609,25 @@ impl PartialOrd for Window {
2609
2609
}
2610
2610
2611
2611
/// Communicates the desired ordering of the output of a scan operation.
2612
-
///
2612
+
///
2613
2613
/// 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
2615
2615
/// to the scan about what might help.
2616
-
///
2616
+
///
2617
2617
/// For example, a query with `ORDER BY time DESC LIMIT 10`, DataFusion's dynamic
2618
2618
/// predicates and TopK operator will work better if the data is roughly ordered by descending
2619
2619
/// time (more recent data first).
2620
-
///
2620
+
///
2621
2621
/// Implementers of [`TableProvider`] should use this information to optimize the order in which data is output from the scan.
2622
-
///
2622
+
///
2623
2623
/// It is a hint and not a requirement:
2624
2624
/// - 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.
2625
2625
/// - 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.
2626
2626
/// - 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
2629
2629
/// 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`]
2631
2631
/// you produce reflects the ordering in it's properties.
0 commit comments