### What problem does this PR solve?
Problem Summary:
DeletePredicatePB should be DeleteSubPredicatePB.
Test case is too ambiguous to add, since this bug is triggered by a huge
random test and failed to find the minimal case. However, this fix is
verified under the wild test that it does works.
Note that this problem may be triggered by another bug, cuz schema in
delete predicate rowset should contain column referred in delete
condition. Even if we don't have this fix, this error should never
happend.
But this error occurred under wild tests, means that schema in delete
predicate rowset is not adaptable with delete condition. I think it is
under some status that delete operation use BE tablet schema rather than
schema from FE, and the former rename operation result in that status.
But I failed to add a test case to reproduce, and think that by no way
will it happend occurding to the related code.
```
(1105, 'errCode = 2, detailMessage = ([172.20.50.7](http://172.20.50.7/))[INTERNAL_ERROR]failed to initialize storage reader. tablet=78026, res=[INTERNAL_ERROR]column not found, name=loc1, table_id=-1, schema_version=2
\t0# doris::TabletSchema::column(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:375
\t1# doris::Status doris::DeleteHandler::_parse_column_pred<doris::DeleteSubPredicatePB>(std::shared_ptr<doris::TabletSchema>, std::shared_ptr<doris::TabletSchema>, google::protobuf::RepeatedPtrField<doris::DeleteSubPredicatePB> const&, doris::DeleteConditions*) at /home/zcp/repo_center/doris_master/doris/be/src/util/expected.hpp:1986
\t2# doris::DeleteHandler::init(std::shared_ptr<doris::TabletSchema>, std::vector<std::shared_ptr<doris::RowsetMeta>, std::allocator<std::shared_ptr<doris::RowsetMeta> > > const&, long) at /var/local/ldb-toolchain/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:701
\t3# doris::TabletReader::_init_delete_condition(doris::TabletReader::ReaderParams const&) at /var/local/ldb-toolchain/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:701
\t4# doris::TabletReader::_init_params(doris::TabletReader::ReaderParams const&) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t5# doris::TabletReader::init(doris::TabletReader::ReaderParams const&) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t6# doris::vectorized::BlockReader::init(doris::TabletReader::ReaderParams const&) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t7# doris::vectorized::NewOlapScanner::open(doris::RuntimeState*) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:499
\t8# doris::vectorized::ScannerScheduler::_scanner_scan(std::shared_ptr<doris::vectorized::ScannerContext>, std::shared_ptr<doris::vectorized::ScanTask>) at /home/zcp/repo_center/doris_master/doris/be/src/common/status.h:388
\t9# std::_Function_handler<void (), doris::vectorized::ScannerScheduler::submit(std::shared_ptr<doris::vectorized::ScannerContext>, std::shared_ptr<doris::vectorized::ScanTask>)::$_1::operator()() const::{lambda()#1}>::_M_invoke(std::_Any_data const&) at /var/local/ldb-toolchain/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:701
\t10# doris::ThreadPool::dispatch_thread() at /home/zcp/repo_center/doris_master/doris/be/src/util/threadpool.cpp:0
\t11# doris::Thread::supervise_thread(void*) at /var/local/ldb-toolchain/bin/../usr/include/pthread.h:562
\t12# ?
\t13# ?
, backend=[172.20.50.7](http://172.20.50.7/)')
```
```cpp
auto tablet_schema = std::make_shared<TabletSchema>();
tablet_schema->copy_from(*tablet->tablet_schema());
if (!request.columns_desc.empty() && request.columns_desc[0].col_unique_id >= 0) {
tablet_schema->clear_columns();
// TODO(lhy) handle variant
for (const auto& column_desc : request.columns_desc) {
tablet_schema->append_column(TabletColumn(column_desc));
}
}
RowsetSharedPtr rowset_to_add;
// writes
res = _convert_v2(tablet, &rowset_to_add, tablet_schema, push_type);
if (!res.ok()) {
LOG(WARNING) << "fail to convert tmp file when realtime push. res=" << res
<< ", failed to process realtime push."
<< ", tablet=" << tablet->tablet_id()
<< ", transaction_id=" << request.transaction_id;
Status rollback_status = _engine.txn_manager()->rollback_txn(request.partition_id, *tablet,
request.transaction_id);
// has to check rollback status to ensure not delete a committed rowset
if (rollback_status.ok()) {
_engine.add_unused_rowset(rowset_to_add);
}
return res;
}
// add pending data to tablet
if (push_type == PushType::PUSH_FOR_DELETE) {
rowset_to_add->rowset_meta()->set_delete_predicate(std::move(del_preds.front()));
del_preds.pop();
}
```
… (#38759)
https://github.com/apache/doris/pull/38759
The main issue is that _mm_movemask_epi8 does not have a one-to-one
corresponding instruction on ARM. Testing shows that it performs worse
compared to using memcmp, which allows the compiler to generate the
corresponding ARM instructions.
The following tests were conducted on ARM.
```
--------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------
BM_memequal16_sse 3.77 ns 3.77 ns 743238946
BM_memequal16_orgin 2.11 ns 2.11 ns 1000000000
```
https://github.com/apache/doris/pull/38360
The previous code only considered the x86 architecture, and
_mm_movemask_epi8 does not have a corresponding instruction in ARM.
According to the article below, we need to abstract the overall logic.
For ARM, optimize using the content mentioned in the following article:
filter function origin 0.711375 seconds 0.7154 seconds 0.71782 seconds
0.715296 seconds
filter function arm opt 0.559854 seconds 0.559854 seconds 0.559854
seconds 0.559854 seconds
### What problem does this PR solve?
If enable_verbose_profile is false, update_rpc_time will not be called,
and RPC count, max, and min statistics will not be recorded.
```
- RpcCount: 0
- RpcMaxTime: 0ns
- RpcMinTime: 0ns
- RpcSumTime: 0ns
```
Co-authored-by: Mryange <yanxuecheng@selectdb.com>
bp #42882#43246#43336
We pick these PRs together because they all fix one problem and if not
do so, the regression test won't be passed.
---------
Co-authored-by: Sun Chenyang <csun5285@gmail.com>
Co-authored-by: qidaye <luen@selectdb.com>
Reverts apache/doris#42255
We have found that after closing the connection pool, there will be
class loading problems and connection release problems for some data
sources. We will remove this function first and re-add it after solving
and testing it completely.
```
insert into t1 (k1, k2, v1) value(1, '', 2);
delete form t1 where k1 = 1 and k2 = '';
alter table modify column v1 string
select * from t1 // expect 0 rows in return, but get 1 row.
```
pick master #41737
## problem
CREATE TABLE t (
`k1` VARCHAR(30) NOT NULL,
`v1` INT NOT NULL
)
alter table t modify column `v1` INT NULL
insert into value ('1', 2), ('1', 3);
core dump
## reason
Schema change leads to double writing, during double writing, the two
schemas and slots are as follows
```
old tablet schema
k1 varchar not null
v1 int not null
```
```
new tablet scheam
k1 varchar not null
v1 int null
```
```
slot
k1 varchar not null
v1 int not null
v1 int null
```
During the double writing process, when selecting slots through the
schema, only the column names and types were compared, without comparing
the nullable attributes, which led to the selection of the wrong slot.
Since the slot determines the nullable attribute of the block, the
nullable attribute of the columns in the block is different from that of
the columns in the schema, resulting in a core dump.
## Proposed changes
Issue Number: close #xxx
<!--Describe your changes.-->
