Description
This is a feature request to remove the Vectorization 2.0 framework from the codebase. The proposal is to retain Vectorization 1.0 (controlled by the _rowsets_enabled parameter) and remove the Vectorization 2.0 components (controlled by use_rich_format_ and _enable_rich_vector_format parameters).
Technical Context
Vectorization 1.0:
- Operators process multiple rows per call:
get_next_row -> get_next_batch.
- Expressions compute a batch at a time:
expr->eval -> expr->eval_batch.
- Storage decodes data in batches to
ObDatum.
Vectorization 2.0:
Vectorization 2.0 is an extension of 1.0, focusing on changes to the "physical representation of each column" and the "computational kernel".
Changes in Physical Representation:
- 1.0: Each column is a fixed array of
ObDatum datums[256].
- 2.0: Dynamically selects different formats (
IVector/Rich Format) based on data type and source to reduce format conversion, branching, and data access overhead, and provides opportunities for SIMD optimization for some operators.
VEC_FIXED: Fixed-length basic types (e.g., int, float).
VEC_CONTINUOUS: Multiple variable-length varchars stored on a contiguous memory block.
VEC_DISCRETE: For example, string content of varchar expressions after operator computation stored in discrete memory.
VEC_UNIFORM: Compatible with the ObDatum representation from 1.0.
VEC_UNIFORM_CONST
Changes in Computational Kernel:
eval_batch_func_ -> eval_vector_func_: The latter supports multiple columnar memory formats and type specialization.
Code Impact
The removal will affect the following code paths:
src/sql/engine/vector/**
src/sql/engine/expr/vector_cast/**
# Various vec operators
src/sql/engine/aggregate/ob_exec_hash_struct_vec.*
src/sql/engine/basic/ob_limit_vec_op.*
src/sql/engine/join/ob_join_vec_op.*
# Rich Aggregate new framework
src/sql/engine/aggregate/
Should retain ObAggregateProcessor, remove share::aggregate::Processor
src/sql/dtl/ob_dtl_vectors_buffer.cpp
src/sql/dtl/ob_dtl_vectors_buffer.h
# storage
src/storage/blocksstable/encoding/*
src/storage/access/ob_aggregated_store_vec.*
src/storage/access/ob_pushdown_aggregate_vec.*
Additional Notes
- Regarding session pool overhead: The actual overhead is in Session allocation, which is now dynamic. This pool has minimal practical effect.
- For issues reported by external business teams, please correctly select the "Work Item Type" on the right based on the actual situation:
- Customer Service Feedback: Specifically refers to issues before deployment/POC, clearly identified as product bugs requiring fixes and release.
- Online Issue: Issues that have occurred after deployment, clearly identified as product bugs, but not classified as a fault.
- Online Fault: Issues that have occurred after deployment, clearly identified as product bugs, causing business errors or negative impact on the customer side (the interpretation of a fault belongs to the delivery service team).
Description
This is a feature request to remove the Vectorization 2.0 framework from the codebase. The proposal is to retain Vectorization 1.0 (controlled by the
_rowsets_enabledparameter) and remove the Vectorization 2.0 components (controlled byuse_rich_format_and_enable_rich_vector_formatparameters).Technical Context
Vectorization 1.0:
get_next_row->get_next_batch.expr->eval->expr->eval_batch.ObDatum.Vectorization 2.0:
Vectorization 2.0 is an extension of 1.0, focusing on changes to the "physical representation of each column" and the "computational kernel".
Changes in Physical Representation:
ObDatum datums[256].IVector/Rich Format) based on data type and source to reduce format conversion, branching, and data access overhead, and provides opportunities for SIMD optimization for some operators.VEC_FIXED: Fixed-length basic types (e.g., int, float).VEC_CONTINUOUS: Multiple variable-length varchars stored on a contiguous memory block.VEC_DISCRETE: For example, string content of varchar expressions after operator computation stored in discrete memory.VEC_UNIFORM: Compatible with theObDatumrepresentation from 1.0.VEC_UNIFORM_CONSTChanges in Computational Kernel:
eval_batch_func_->eval_vector_func_: The latter supports multiple columnar memory formats and type specialization.Code Impact
The removal will affect the following code paths:
Additional Notes