perf: window operator performance degradation

[sundy-li]

Summary

------- query internal/09.sql -------
select max(number) over (partition by number % 3 order by number), rank() over (partition by number % 3 order by number) from numbers(20000000) where number % 100 != 0 ignore_result;

[forsaken628]

I compared the v636 and v700 implementations, and the main difference is that #16448 introduces ShufflePartition in WindowPartition.
The v636 implementation is very sensitive to whether the original data is sorted or not. For sorted data, the entire sorting process can be skipped. But on the other hand, if the original data is not sorted, it will consume more cpu time on sorting.

See the following benchmark

create warehouse 'v636' warehouse_size='xsmall' with version='v1.2.636-nightly';
create warehouse 'v700' warehouse_size='xsmall' with version='v1.2.700-nightly';

create table rand (number UINT64 not null) ENGINE=RANDOM;
create table t1 (number UINT64 not null);
insert into t1 select number % 20000000 from rand limit 20000000;

explain analyze select max(number) over (partition by number % 3 order by number), rank() over (partition by number % 3 order by number) from t1 where number % 100 != 0 ignore_result;
-- 636 total 5s   WindowPartition cpu time: 9.995544112s
-- 700 total 6.1s WindowPartition cpu time: 5.09495319s

explain analyze select max(number) over (partition by number % 3 order by number), rank() over (partition by number % 3 order by number) from numbers(20000000) where number % 100 != 0 ignore_result;
-- 636 total 1.4s WindowPartition cpu time: 987.903091ms
-- 700 total 3.9s WindowPartition cpu time: 2.752338919s

I don't think the internal/09.sql use case is representative of overall performance.

cc @Dousir9

[sundy-li]

explain analyze select max(number) over (partition by number % 3 order by number), rank() over (partition by number % 3 order by number) from t1 where number % 100 != 0 ignore_result;
-- 636 total 5s WindowPartition cpu time: 9.995544112s
-- 700 total 6.1s WindowPartition cpu time: 5.09495319s

Ok, seems internal/09.sql use case is not suitable for benchmark validation.