Skip to content

[Epic] Unify AggregateFunction Interface (remove built in list of AggregateFunction s), improve the system #8708

Closed

Description

@alamb

Is your feature request related to a problem or challenge?

For many of the same reasons as listed on #8045, having two types of aggregate functions ("built in" -- datafusion::physical_plan::aggregates::AggregateFunction) and AggregateUDF is problematic for two reasons:

  1. There are some features not available to User Defined Aggregate Functions (such as the faster GroupsAccumulator interface)
  2. Users can not easily choose which aggregate functions to include (for example, do they want to allow (and pay the code size / compile time) for the Statistical and Approximate functions

The second also ends up causing pushback on adding new aggregates like ARRAY_SUM in #8325 and geospatial support #7859.

Describe the solution you'd like

I propose moving DataFusion to only use AggregateUDFs and remove the built in list of AggregateFunctions for the same reasons as #8045

We will keep the existing AggregateUDF interface as much as possible, while also potentially providing an easier way to define them.

New AggregateUDF is in functions-aggregate crate
Old Aggregate functions are in datafusion/physical-expr/src/aggregate

Describe alternatives you've considered

Additional context

Proposed implementation steps:

Move rust test to sqllogictest if possible #10384

Good first issue list

Pending

  • nth_value
  • array_agg_distinct
  • array_agg_ordered
impl FromStr for AggregateFunction {
    type Err = DataFusionError;
    fn from_str(name: &str) -> Result<AggregateFunction> {
        Ok(match name {
            // general
            "avg" => AggregateFunction::Avg,
            "bit_and" => AggregateFunction::BitAnd,
            "bit_or" => AggregateFunction::BitOr,
            "bit_xor" => AggregateFunction::BitXor,
            "bool_and" => AggregateFunction::BoolAnd,
            "bool_or" => AggregateFunction::BoolOr,
            "max" => AggregateFunction::Max,
            "mean" => AggregateFunction::Avg,
            "min" => AggregateFunction::Min,
            "array_agg" => AggregateFunction::ArrayAgg,
            "nth_value" => AggregateFunction::NthValue,
            "string_agg" => AggregateFunction::StringAgg,
            // statistical
            "corr" => AggregateFunction::Correlation,
            // other
            "grouping" => AggregateFunction::Grouping,
            _ => {
                return plan_err!("There is no built-in function named {name}");
            }
        })
    }
}

Feel free to file an issue if you are interested in working on any of the above in the pending list.

Activity

  1. changed the title [-][Epic] Unify `AggregateFunction` Interface (remove built in list of `AggregateFunction` s)[/-] [+][Epic] Unify `AggregateFunction` Interface (remove built in list of `AggregateFunction` s), improve the system[/+] on Jan 8, 2024
  2. jayzhan211 commented on Mar 26, 2024

    @jayzhan211
    Contributor

    I will work on FirstValue UDF together with #9249

  3. jayzhan211 commented on Mar 27, 2024

    @jayzhan211
    Contributor

    Can we introduce state_fields and fields for AggregateUDFImpl. We can see that types in AggregateUDFImpl are for building fields, why not just return fields directly, we can not only define the types but also the field name and is_nullalbe.

    https://github.com/apache/arrow-datafusion/blob/e337832946fc69f6ceccd14b96a071cc2cd4693d/datafusion/physical-plan/src/udaf.rs#L86-L106

  4. alamb commented on Mar 27, 2024

    @alamb
    ContributorAuthor

    Thank you @jayzhan211 -- I am traveling this week so I am very behind on reviews. I will try and respond later this week

  5. jayzhan211 commented on Mar 27, 2024

    @jayzhan211
    Contributor

    Thank you @jayzhan211 -- I am traveling this week so I am very behind on reviews. I will try and respond later this week

    I leave the comment so I won't forget.
    Have a good trip 😊

  6. jayzhan211 commented on Mar 29, 2024

    @jayzhan211
  7. alamb commented on May 25, 2024

    @alamb
    ContributorAuthor

    After #10648 and #10389 I think we have a pretty good set of examples of how to move aggregates out of the core (thanks to all the foundations layed by @jayzhan211 )

    Would it be helpful to file a few "good first issue" type tickets for some of the more straightforward aggregates (I am thinking the statistical variance etc)?

  8. jayzhan211 commented on May 25, 2024

    @jayzhan211
    Contributor

    After #10648 and #10389 I think we have a pretty good set of examples of how to move aggregates out of the core (thanks to all the foundations layed by @jayzhan211 )

    Would it be helpful to file a few "good first issue" type tickets for some of the more straightforward aggregates (I am thinking the statistical variance etc)?

    Before this, I think it would be nice to determine the expression API of aggregate function first #10560 (comment)

  9. alamb commented on Mar 11, 2025

    @alamb
    ContributorAuthor

    I believe we have completed this work (to remove built in aggregates!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions