Naive implementation of OneByOneAggr, suitable for stuff like const folding, but too slow for
rendering. This relies only on infrastructure available in mz-expr. It simply saves all the
given input, and calls the given AggregateFuncโs eval method when asked about the current
aggregate. (For Accumulable and Hierarchical aggregations, the rendering has more efficient
implementations, but for Basic aggregations even the rendering uses this naive implementation.)
Evaluates the inner table function, expands its results into unary (repeating each row as
many times as the diff indicates), and appends an integer corresponding to the ordinal
position (starting from 1). For example, it numbers the elements of a list when calling
unnest_list.
An implementation of an aggregation where we can send in the input elements one-by-one, and
can also ask the current aggregate at any moment. (This just delegates to other aggregation
evaluation approaches.)
The expected input is in the format of [((OriginalRow, [EncodedArgs]), OrderByExprs...)]
The output is in the format of [result_value, original_row].
See an example at lag_lead, where the input-output formats are similar.
Executes FusedValueWindowFunc on a reduction group.
The expected input is in the format of [((OriginalRow, (Args1, Args2, ...)), OrderByExprs...)]
where Args1, Args2, are the arguments of each of the fused functions. For functions that
have only a single argument (first_value/last_value), these are simple values. For functions
that have multiple arguments (lag/lead), these are also records.
Computes a bundle of fused window aggregations.
The input is similar to window_aggr, but InputValue is not just a single value, but a record
where each component is the input to one of the aggregations.
Assuming datums is a List, sort them by the 2nd through Nth elements
corresponding to order_by, then return the 1st element and computed order by expression.
The expected input is in the format of [((OriginalRow, [EncodedArgs]), OrderByExprs...)]
The output is in the format of [result_value, original_row].
See an example at lag_lead, where the input-output formats are similar.
The expected input is in the format of [((OriginalRow, [EncodedArgs]), OrderByExprs...)]
The output is in the format of [result_value, original_row].
See an example at lag_lead, where the input-output formats are similar.
Sums intervals component-wise, as PostgreSQLโs interval addition does:
months, days, and microseconds each accumulate on their own, and nothing is
carried from a coarser component into a finer one.
Count-aware interval sum. Accumulates ฮฃ valueยทdiff per interval component
in i128, which matches Accum::Interval in mz_compute::render::reduce;
the narrowing back to the Interval field widths reproduces that variantโs
finalize_accum arm. Consuming the multiplicity directly keeps this linear
in the number of distinct values and correct for negative diffs
(retractions), which expand_counts would silently drop.
Count-aware signed-integer sum. Accumulates ฮฃ valueยทdiff in i128, which
matches the width of the dataflowโs Accum::SimpleNumber accumulator (see
build_accumulable and finalize_accum in mz_compute::render::reduce);
narrow then reproduces that variantโs finalize_accum arm. Unlike
expand_counts, this consumes the multiplicity directly, so it is linear in
the number of distinct values and correct for negative diffs (retractions),
which expand_counts would silently drop.
input_datums is an entire window partition.
The expected input is in the format of [((OriginalRow, InputValue), OrderByExprs...)]
See also in the comment in window_func_applied_to.