You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2022/05/09 12:57:18 UTC

[GitHub] [arrow-datafusion] alamb commented on a diff in pull request #2446: Add SQL planner support for `ROLLUP` and `CUBE` grouping set expressions

alamb commented on code in PR #2446:
URL: https://github.com/apache/arrow-datafusion/pull/2446#discussion_r867982502


##########
datafusion/expr/src/expr_schema.rs:
##########
@@ -198,6 +202,11 @@ impl ExprSchemable for Expr {
                 let data_type = expr.get_type(input_schema)?;
                 get_indexed_field(&data_type, key).map(|x| x.is_nullable())
             }
+            Expr::GroupingSet(_) => {
+                // grouping sets do not really have the concept of nullable and do not appear

Review Comment:
   I wonder if it is worth considering representing the grouping sets in a more specific way (like maybe a specific list on `LogicalPlan::Aggregrate`) rather than an `Expr` that can appear anywhere
   
   
   
   ```rust
   enum GroupingExpr {
     Expr(Expr),
     GroupingSet(GroupingSet),
   }
   
   /// Aggregates its input based on a set of grouping and aggregate
   /// expressions (e.g. SUM).
   #[derive(Clone)]
   pub struct Aggregate {
       /// The incoming logical plan
       pub input: Arc<LogicalPlan>,
       /// Grouping expressions
       pub group_expr: Vec<AggExprs>,
       /// Aggregate expressions
       pub aggr_expr: Vec<Expr>,
       /// The schema description of the aggregate output
       pub schema: DFSchemaRef,
   }
   ```
   
   Or something?



##########
datafusion/expr/src/expr.rs:
##########
@@ -249,6 +249,24 @@ pub enum Expr {
     Wildcard,
     /// Represents a reference to all fields in a specific schema.
     QualifiedWildcard { qualifier: String },
+    /// List of grouping set expressions. Only valid in the context of an aggregate

Review Comment:
   While reviewing this PR I was wondering how you aim to plan these queries
   
   it seems like a simple way would be to expand them to a set of `UNION ALL` queries, though then we will likely do the same input query many times which may be unideal. 
   
   Anyhow, I am looking forward to the next installment



-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org