zhuqi-lucas commented on code in PR #23523:
URL: https://github.com/apache/datafusion/pull/23523#discussion_r3579572822


##########
datafusion/physical-plan/src/aggregates/group_values/multi_group_by/row_backed.rs:
##########
@@ -0,0 +1,373 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+//! A generic [`GroupColumn`] backed by the arrow row format.
+//!
+//! Unlike the type-specialized builders in this module (primitive, byte,
+//! boolean, ...), [`RowsGroupColumn`] works for *any* data type that arrow's
+//! [`RowConverter`] can encode — including nested types such as `Struct`,
+//! `List`, `LargeList` and `FixedSizeList`. It stores one group value per row
+//! in a single-column [`Rows`] buffer and compares group keys by their encoded
+//! bytes.
+//!
+//! # Why this exists
+//!
+//! [`GroupValuesColumn`] can only be used when *every* column of the group-by
+//! key has a [`GroupColumn`] implementation; otherwise the whole aggregation
+//! falls back to the row-wise [`GroupValuesRows`], which is materially slower
+//! and heavier for the columns that *would* have qualified for the column-wise
+//! fast path. By providing a generic fallback `GroupColumn`, a schema like
+//! `GROUP BY int_col, struct_col` keeps `int_col` on its fast native builder
+//! and only pays the row-encoding cost on `struct_col`, instead of dragging 
the
+//! entire key onto `GroupValuesRows`.
+//!
+//! # Relationship to hashing
+//!
+//! This column does not hash anything itself: [`GroupValuesColumn`] hashes the
+//! raw input columns via `create_hashes`, which already supports nested types.
+//! Equality is decided here by comparing arrow-row bytes. For the two to agree
+//! on group identity, values that this column considers equal must hash equal 
—
+//! see the float `-0.0` / `NaN` note on [`RowsGroupColumn`].
+//!
+//! [`GroupValuesColumn`]: 
crate::aggregates::group_values::multi_group_by::GroupValuesColumn
+//! [`GroupValuesRows`]: crate::aggregates::group_values::GroupValuesRows
+
+use crate::aggregates::group_values::multi_group_by::GroupColumn;
+use crate::aggregates::group_values::row::dictionary_encode_if_necessary;
+
+use arrow::array::{Array, ArrayRef, BooleanBufferBuilder};
+use arrow::datatypes::DataType;
+use arrow::row::{RowConverter, Rows, SortField};
+use datafusion_common::{DataFusionError, Result};
+
+/// A [`GroupColumn`] that stores group values for a single column in the arrow
+/// [row format], backed by a single-field [`RowConverter`].
+///
+/// # NULL semantics
+///
+/// The [`GroupColumn`] contract treats two NULLs as equal. The row format
+/// encodes NULL with a distinct sentinel, so `null`-row bytes compare equal to
+/// each other and unequal to any non-null row — matching the contract without
+/// special-casing.
+///
+/// # Float `-0.0` / `NaN`
+///
+/// Equality here is byte equality under arrow's IEEE-754 *totalOrder* row
+/// encoding, which treats `-0.0` and `+0.0` as distinct and canonicalizes
+/// `NaN`. Because hashing is performed separately (on the raw input array), a
+/// caller must ensure the two agree — e.g. by normalizing `-0.0 → +0.0` on the
+/// input columns before hashing when a float leaf is present (as
+/// [`GroupValuesRows`] does). See the module docs.
+///
+/// [row format]: arrow::row
+/// [`GroupValuesRows`]: crate::aggregates::group_values::GroupValuesRows
+pub struct RowsGroupColumn {
+    /// Single-field row converter for this column's data type.
+    row_converter: RowConverter,
+    /// Accumulated group values in row format; `group_values.row(i)` is the
+    /// group value for group index `i`.
+    group_values: Rows,
+    /// The column's expected output type. The row format decodes dictionary /
+    /// run-end encoded values to their plain value type, so emitted arrays are
+    /// re-encoded to this type in `build` / `take_n` (mirroring
+    /// `GroupValuesRows::emit`).
+    output_type: DataType,
+}
+
+impl RowsGroupColumn {
+    /// Returns whether `data_type` can be handled by this generic column, i.e.
+    /// whether arrow's [`RowConverter`] can encode it.
+    pub fn supports_type(data_type: &DataType) -> bool {
+        RowConverter::supports_fields(&[SortField::new(data_type.clone())])
+    }
+
+    /// Create an empty [`RowsGroupColumn`] for `data_type`.
+    pub fn try_new(data_type: DataType) -> Result<Self> {
+        let row_converter = 
RowConverter::new(vec![SortField::new(data_type.clone())])?;
+        let group_values = row_converter.empty_rows(0, 0);
+        Ok(Self {
+            row_converter,
+            group_values,
+            output_type: data_type,
+        })
+    }
+
+    /// Materialize `rows` into a single array of `self.output_type`, 
re-applying
+    /// dictionary / run-end encoding the row format strips on decode.
+    fn rows_to_array<'a>(
+        &self,
+        rows: impl IntoIterator<Item = arrow::row::Row<'a>>,
+    ) -> ArrayRef {
+        let mut arrays = self
+            .row_converter
+            .convert_rows(rows)
+            .expect("row conversion during emit");

Review Comment:
   They're about skipping utf8 validation in `RowParser`, not about the 
dict/REE re-encoding path. The connection to this PR is that `RowsGroupColumn` 
runs everything through `RowConverter` (built on `RowParser`), so once the 
`validate_utf8 = false` opt-out lands upstream we could plumb it through for a 
small row-encode speedup on string / binary group keys. Won't block on it here 
— good to keep on the radar though, thanks for the pointer.



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to