Enable two phase partition topn optimization, instead of original full sort at the second phase.
E.g, partial plan of tpcds q67 is as following and a full sort after exchange will have performance impact, especially if the window column's ndv is very high and the number of window is huge.
------PhysicalTopN
--------filter((rk <= 100))
----------PhysicalWindow
------------PhysicalQuickSort
--------------PhysicalDistribute
----------------PhysicalPartitionTopN
------------------PhysicalProject
Under this scenario, the second phase full sort can be transformed to a global PhysicalPartitionTopN and reduce the cost from full sort. The plan will be optimized to the following:
------PhysicalTopN
--------filter((rk <= 100))
----------PhysicalWindow
------------PhysicalPartitionTopN
--------------PhysicalDistribute
----------------PhysicalPartitionTopN
------------------PhysicalProject
A Simplified Version of the Profile
Divided into three levels:
Level 2: The original profile.
Level 1: Instances with identical structures are merged, utilizing concatenation for info strings, and recording the extremum for time types.
Note that currently, this is purely experimental, simplifying the profile on the frontend (you can view profiles at any level).
Subsequently, we will transition the simplification process to the backend. At that point, due to the simplification being done on the backend, viewing profiles at other levels won't be possible.
Due to the issue with the pipeline structure, the active time does not accurately reflect the time of the operators.
```
set enable_simply_profile = false;
set enable_simply_profile = true;
```
* When BDBJEJournal.write meet `ReplicaWriteException`, we should not
retry. Because at the monment the bdbje node state is `REPLICA` (not `MASTER`)
if we still retry write, at the same time trigger election, the orgin `REPLICA`
node may transfer to `MASTER` and will cause incorrect journalId
Co-authored-by: yiguolei <676222867@qq.com>
### Support dispaly of auto analyze jobs
After this PR, users and DBA could use such grammar to check the execution status of auto analyze jobs:
```sql
SHOW AUTO ANALYZE [tbl_name] [WHERE STATE='SOME STATE']
```
Record count of history auto analyze job could be configured by setting FE option: auto_analyze_job_record_count, default value is 2000
### Enhance auto analyze
After this PR, auto jobs those created automatically will no longer execute beyond a specific time frame.
the nereids planner may reorder the join without any statistics info. This could lead to very bad join order that cause the query timeout. This pr disable join reorder for this sql.
