yjshen commented on a change in pull request #1782: URL: https://github.com/apache/arrow-datafusion/pull/1782#discussion_r803798784
########## File path: datafusion/src/row/mod.rs ########## @@ -0,0 +1,334 @@ +// 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. + +//! An implementation of Row backed by raw bytes +//! +//! Each tuple consists of up to three parts: [null bit set] [values] [var length data] +//! +//! The null bit set is used for null tracking and is aligned to 1-byte. It stores +//! one bit per field. +//! +//! In the region of the values, we store the fields in the order they are defined in the schema. Review comment: > finding where Row3 starts in the following picture needs to scan all columns of Row1 and Row2 I think since we are doing in-memory processing, we can actually store each row's starting offset as a separate vector. just like the method shows: ```rust pub fn write_batch_unchecked( output: &mut [u8], offset: usize, batch: &RecordBatch, row_idx: usize, schema: Arc<Schema>, ) -> Vec<usize> { let mut writer = RowWriter::new(&schema); let mut current_offset = offset; let mut offsets = vec![]; for cur_row in row_idx..batch.num_rows() { offsets.push(current_offset); let row_width = write_row(&mut writer, cur_row, batch); output[current_offset..current_offset + row_width] .copy_from_slice(writer.get_row()); current_offset += row_width; writer.reset() } offsets } ``` I'm thinking of just keeping the offset vector we got while writing, and using it hereafter. > I think getting optimal performance will come from being able to vectorize many operations for which fixed sized tuples are compelling: I'm afraid it will be hard to vectorize the operation on a row format since row width may easily exceed the SIMD lane? > filling the variable length area from the back. Yes, I'm aware of the strategy. but we are using rows mainly during execution, unlike the DBMS systems using this to keep tuples in long-term stores, I think we can just store offset separately in a vector? -- 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-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
