[feat](fe) Support rolling upgrades of partition inverted index formats by hoshinojyunn · Pull Request #66017 · apache/doris

hoshinojyunn · 2026-07-24T12:02:28Z

What problem does this PR solve?

Issue Number: None

Related PR: #57013

Problem Summary:

An inverted-index storage-format rollout must not rewrite historical tablets. A table can therefore contain V2 partitions created before the rollout and V3 partitions created afterwards. Before this change, the format selected for a future partition was not persisted as partition metadata, so lifecycle paths could not consistently preserve the format that the partition requires.

This PR introduces partition.inverted_index_storage_format for future logical partitions. It resolves and persists V2 or V3 in PartitionInfo, and passes that value to tablet and replica creation. Changing the property does not modify existing partitions.

Implementation changes:

Add the partition-scoped property; V1 is rejected and V2/V3 are supported.
Preserve the resolved format for initial, manual, auto, and dynamic partitions.
Persist the format in add-partition edit-log records and restore it during edit-log replay.
Preserve it through restore, recycle-bin recovery, truncate, insert overwrite, schema change, and replica recovery.
Expose the partition format in SHOW PARTITIONS, SHOW PARTITION <partition_id>, partitions(...), and SHOW CREATE TABLE.

Example SQL:

CREATE TABLE db.t (
    k DATE NOT NULL,
    v VARCHAR(100),
    INDEX idx_v (v) USING INVERTED PROPERTIES("parser" = "english")
)
ENGINE=OLAP
DUPLICATE KEY(k)
PARTITION BY RANGE(k) (
    PARTITION p_old VALUES LESS THAN ("2024-01-01")
)
DISTRIBUTED BY HASH(k) BUCKETS 1
PROPERTIES (
    "replication_num" = "1",
    "inverted_index_storage_format" = "V2"
);

ALTER TABLE db.t
SET ("partition.inverted_index_storage_format" = "V3");

ALTER TABLE db.t
ADD PARTITION p_new VALUES [("2024-01-01"), ("2025-01-01"));

SHOW PARTITIONS FROM db.t;
SHOW TABLETS FROM db.t PARTITION(p_new);

Observability result:

Partition	FE metadata (`SHOW PARTITIONS` / `partitions(...)`)	BE tablet header (`GET <MetaUrl>`)
`p_old`	`InvertedIndexStorageFormat = V2`	`schema.inverted_index_storage_format = "V2"`
`p_new`	`InvertedIndexStorageFormat = V3`	`schema.inverted_index_storage_format = "V3"`

SHOW TABLETS FROM db.t PARTITION(p_new) provides each tablet MetaUrl. Requesting the URL verifies the format stored in the actual BE tablet metadata, not only the FE partition metadata.

Cloud mode support and validation

Cloud mode handles this property change in CloudSchemaChangeHandler; the generic SchemaChangeHandler remains unchanged for this purpose. When partition.inverted_index_storage_format changes, every MaterializedIndexMeta advances to its next schema version, and the exact per-index target versions are persisted in ModifyTablePropertyOperationLog.

Cloud schema records are keyed by (index_id, schema_version). This retains the old V2 schema record for existing tablet metadata while newly created partitions use the new V3 (or rolled-back V2) version, so the formats coexist without rewriting historical tablets.

Cloud regression coverage adds cloud_p0/test_partition_cloud_inverted_index_storage_format_rollout. It exercises RANGE, LIST, AUTO LIST, and DYNAMIC RANGE partitions across V2 -> V3 -> V2 rollouts; mixed-format inverted-index queries; INSERT OVERWRITE; SHOW PARTITION; and the schema format from every tablet MetaUrl.

Release note

Users can roll out V3 inverted-index storage format to newly created partitions without changing historical partitions.

Check List (For Author)

Test
- Regression test
- Unit Test
- Manual test (add detailed scripts or steps below)
- No need to test or manual test. Explain why:
  - This is a refactor/code format and no logic has been changed.
  - Previous test can cover this change.
  - No code files have been changed.
  - Other reason

Partition-type regression coverage:

Partition type	Test SQL / operation	Asserted result	Regression case / status
RANGE	Create `p_old` with table format V2; set `partition.inverted_index_storage_format` to V3; `ADD PARTITION p_new`.	`p_old` remains V2 and `p_new` is V3 in both `SHOW PARTITION` and every tablet MetaUrl. An `INSERT OVERWRITE` of `p_old` also remains V2 after the table property is V3.	`inverted_index_p0/test_partition_inverted_index_storage_format_rollout` (passed)
LIST	Create `p_old` with table format V2; set `partition.inverted_index_storage_format` to V3; `ADD PARTITION p_new`.	`p_old` remains V2 and `p_new` is V3 in both `SHOW PARTITION` and every tablet MetaUrl.	`inverted_index_p0/test_partition_inverted_index_storage_format_rollout` (passed)
AUTO LIST	`CREATE TABLE ... AUTO PARTITION BY LIST(k) ()` with V2; insert `old`; set the partition property to V3; insert `new`.	The auto-created `old` partition remains V2; the newly auto-created partition is V3 in FE metadata and BE tablet headers.	`inverted_index_p0/test_partition_inverted_index_storage_format_rollout` (passed)
DYNAMIC RANGE	Create dynamic partitions with V2 and `dynamic_partition.end = 1`; set the partition property to V3; advance `dynamic_partition.end` to 3.	The three existing dynamic partitions remain V2; the two newly scheduled partitions are V3 in FE metadata and BE tablet headers.	`inverted_index_p0/test_partition_inverted_index_storage_format_rollout` (passed)

All partition-type rows use the same assertion helper: it looks up the partition with SHOW PARTITIONS, checks SHOW PARTITION <partition_id>, then requests the MetaUrl from every row of SHOW TABLETS FROM <table> PARTITION(<partition>). This verifies that the format held by FE and the format stored by BE remain consistent.

Lifecycle and recovery coverage:

Scenario	Test SQL / operation	Asserted result	Coverage / status
Replica recovery	Create V2 `p_v2`, set the property to V3, add `p_v3`, then run `ADMIN SET REPLICA STATUS ... status = "drop"` for a V2 tablet and wait for scheduling.	The replacement replica for `p_v2` is V2; `p_v3` remains V3. Both values are verified through FE metadata and BE tablet headers.	`inverted_index_p2/test_partition_inverted_index_storage_format_replica_recovery` (passed)
Backup and restore	Create V2 partitions `p1`–`p7`, set the property to V3, add `p8`; run `BACKUP SNAPSHOT`, drop the table, then run `RESTORE SNAPSHOT`.	The restored `p1`–`p7` remain V2 and `p8` remains V3; all tablet headers are checked and inverted-index queries succeed.	`backup_restore/test_backup_restore_inverted_idx` (passed with local MinIO)
Edit-log persistence and replay	Serialize an add-partition `PartitionPersistInfo` with V3 and deserialize it; deserialize a legacy record with no format. The replay path consumes this persisted field and restores it to `PartitionInfo`.	V3 survives serialization/deserialization; a legacy record is accepted with no partition format.	`PartitionPersistInfoTest` (passed, 1 test)
Restore partition-ID mapping	Map an old partition ID holding V3 to a new ID with `resetPartitionIdForRestore`.	The restored ID retains V3; dropping the partition removes the stored format.	`RangePartitionInfoTest` (passed, 17 tests)
Create-replica task propagation	Set V3 on a `CreateReplicaTask` and materialize its agent request.	The generated `TCreateTabletReq` carries V3 to BE.	`AgentTaskTest` (passed, 4 tests)
Recycle-bin recovery and truncate	The implementation stores the per-partition format in recycle-bin metadata and derives replacement tablets from the source partition format.	The source partition format is retained on recovery or replacement rather than resolving the current table property.	`inverted_index_p0/test_partition_inverted_index_storage_format_recycle_truncate` (passed); `cloud_p0/test_partition_cloud_inverted_index_storage_format_recycle_truncate` (passed).

Test summary:

Passed ./run-fe-ut.sh --run org.apache.doris.catalog.TablePropertyTest,org.apache.doris.common.PropertyAnalyzerTest.
Passed ./run-fe-ut.sh --run org.apache.doris.catalog.RangePartitionInfoTest,org.apache.doris.persist.PartitionPersistInfoTest,org.apache.doris.task.AgentTaskTest (22 tests, no errors or failures).
Passed DISABLE_BUILD_UI=ON ./build.sh --fe, including FE Checkstyle and packaging.
Passed ./run-regression-test.sh --run -d inverted_index_p0 -s test_partition_inverted_index_storage_format_rollout.
Passed ./run-regression-test.sh --run -d inverted_index_p2 -s test_partition_inverted_index_storage_format_replica_recovery.
Passed ./run-regression-test.sh --run -d backup_restore -s test_backup_restore_inverted_idx with local MinIO.
The local SHOW regression case includes the additional coverage described above but was not rerun in this validation.
Passed ./run-regression-test.sh --run -d cloud_p0 -s test_partition_cloud_inverted_index_storage_format_rollout.
Passed ./run-regression-test.sh --run -d cloud_p0 -s test_partition_cloud_inverted_index_format.
Behavior changed:
- No.
- Yes. Newly created partitions can use a different inverted-index storage format from historical partitions.
Does this need documentation?
- No.
- Yes.

Check List (For Reviewer who merge this PR)

Confirm the release note
Confirm test cases
Confirm document
Add branch pick label

Additional Cloud lifecycle support

Cloud Meta Service stores schemas by (index_id, schema_version). The partition format mapping preserves the logical V2/V3 selection, but Cloud also needs the schema version that each materialized index used when the partition was created. Without it, recreating an old V2 partition after a V3 rollout can resolve the current V3 schema during TRUNCATE.

This change persists the per-index creation-time schema versions for each partition. Cloud recycle-bin recovery and truncate reuse the corresponding source-partition versions; normal new partitions continue to use the current versions. CloudRollupJobV2 also records a rollup index version when the rollup becomes visible. The inverted-index storage format is supplied only to the base index: rollup indexes retain their schema version for Cloud lookup, but do not receive an inverted-index format because they have no secondary inverted index.

Additional lifecycle coverage:

inverted_index_p0/test_partition_inverted_index_storage_format_recycle_truncate covers DROP PARTITION/RECOVER PARTITION, DROP TABLE/RECOVER TABLE, and TRUNCATE TABLE for mixed V2/V3 partitions. It verifies SHOW PARTITION, every base tablet header, replacement tablet IDs, and inverted-index queries.
cloud_p0/test_partition_cloud_inverted_index_storage_format_recycle_truncate mirrors those lifecycle paths with a rollup index. It verifies V2/V3 only on base tablets and confirms the rollup schema has no INVERTED index.

Additional validation:

Passed ./build.sh --fe, including FE Checkstyle.
Passed ./run-regression-test.sh --run -d inverted_index_p0 -s test_partition_inverted_index_storage_format_recycle_truncate.
Manual Cloud runtime validation with the compiled FE JAR copied into the FE container verified partition recovery, table recovery, truncate, mixed-format inverted-index queries, base tablet V2/V3 headers, and rollup schemas without inverted indexes.

Additional Cloud schema-version handling

This round adds the following Cloud-specific behavior.

CloudSchemaChangeHandler continues to reject combined table-property modifications with properties.size() != 1. Therefore partition.inverted_index_storage_format reaches its schema-version update branch only as the sole property; a combined request fails rather than silently skipping the update.
At schema-change job creation, the handler snapshots partitionId -> baseSchemaVersion. It assigns a base shadow schema version for each format represented by existing partitions and the current table format. CloudSchemaChangeJobV2 persists that snapshot in its job JSON (psv), uses it when creating the base shadow tablet metadata for each partition, and restores the selected version on the partition when the shadow index becomes visible. Rollup shadow indexes continue to use their own job schema version.
The mapping is persisted because an AlterJobV2 can be replayed after an FE restart while it is running. Replay must recreate the base shadow index with the same partition-specific schema version that was selected before the restart.
Env.replayModifyTableProperty now accepts legacy ModifyTablePropertyOperationLog records that do not contain indexIdToSchemaVersion, preventing an NPE during edit-log replay.

Additional test coverage:

CloudSchemaChangeJobV2Test verifies partitionIdToBaseSchemaVersion serialization/deserialization and edit-log replay: a base shadow index for a partition restores the recorded version rather than the default shadow version.
EnvTest replays a legacy JSON ModifyTablePropertyOperationLog without indexIdToSchemaVersion and verifies that replay completes.
cloud_p0/test_partition_cloud_inverted_index_storage_format_rollout adds a mixed V2/V3 table with a rollup. It blocks a column schema change in RUNNING, verifies that both V2 and V3 partitions have base and rollup shadow indexes, then completes the job and verifies that the base tablet formats remain V2 and V3 respectively.

Validation status for this round:

All unit tests and regression suites listed above were manually rerun and passed.
This includes the CloudSchemaChangeJobV2Test edit-log replay coverage, the EnvTest legacy ModifyTablePropertyOperationLog replay coverage, and the Cloud mixed V2/V3 schema-change coverage for both base and rollup shadow indexes.

hello-stephen · 2026-07-24T12:02:35Z

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

What problem was fixed (it's best to include specific error reporting information). How it was fixed.
Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
What features were added. Why was this function added?
Which code was refactored and why was this part of the code refactored?
Which functions were optimized and what is the difference before and after the optimization?

### What problem does this PR solve? Issue Number: None Related PR: apache#66017 Problem Summary: Cloud tablet schemas are reused by index ID and schema version. When truncating an older partition after its inverted-index format changes, the current schema version could resolve to a newer V3 schema and recreate a V2 partition with V3 tablet metadata. Persist each partition's schema versions and reuse them during tablet recreation. Apply inverted-index storage format only to the base index; rollup indexes retain their schema versions but do not receive an inverted-index format. ### Release note Cloud partition truncate, recycle-bin recovery, and table recovery preserve each base partition's inverted-index storage format. ### Check List (For Author) - Test: Regression test / Manual test - Regression test: test_partition_inverted_index_storage_format_recycle_truncate - Manual test: Cloud recycle-partition, recover-table, and truncate lifecycle with a rollup index - Build: ./build.sh --fe - Behavior changed: Yes (cloud tablet recreation preserves partition-specific schemas) - Does this need documentation: No

hoshinojyunn · 2026-07-26T04:22:55Z

run buildall

Issue Number: None Related PR: apache#57013 Problem Summary: A table can change its inverted-index storage format, but existing partitions must retain the format used when their tablets were created. Previously, there was no partition-scoped persistent format to distinguish historical tablets from tablets created after a format rollout. This change adds `partition.inverted_index_storage_format` for future logical partitions. The resolved V2 or V3 format is persisted in partition metadata and is passed to tablet and replica creation. Existing partitions are not rewritten, allowing V2 and V3 partitions to coexist while a table rolls forward. The implementation preserves this value through partition creation, auto and dynamic partitioning, edit-log replay, restore, recycle-bin recovery, truncate, insert overwrite, and replica repair. Observability: - `SHOW PARTITIONS`, `SHOW PARTITION <partition_id>`, and `partitions(...)` expose `InvertedIndexStorageFormat`. - `SHOW CREATE TABLE` includes `partition.inverted_index_storage_format` when configured. - `SHOW TABLETS FROM <table> PARTITION(<partition>)` returns each tablet MetaUrl. Requesting `GET <MetaUrl>` returns `schema.inverted_index_storage_format`, which verifies the actual BE tablet metadata. Example SQL: ```sql CREATE TABLE db.t ( k DATE NOT NULL, v VARCHAR(100), INDEX idx_v (v) USING INVERTED PROPERTIES("parser" = "english") ) ENGINE=OLAP DUPLICATE KEY(k) PARTITION BY RANGE(k) ( PARTITION p_old VALUES LESS THAN ("2024-01-01") ) DISTRIBUTED BY HASH(k) BUCKETS 1 PROPERTIES ( "replication_num" = "1", "inverted_index_storage_format" = "V2" ); ALTER TABLE db.t SET ("partition.inverted_index_storage_format" = "V3"); ALTER TABLE db.t ADD PARTITION p_new VALUES [("2024-01-01"), ("2025-01-01")); SHOW PARTITIONS FROM db.t; SHOW TABLETS FROM db.t PARTITION(p_new); ``` Expected observability result: `p_old` reports V2 and its tablet meta header contains `schema.inverted_index_storage_format: "V2"`; `p_new` reports V3 and its tablet meta header contains `schema.inverted_index_storage_format: "V3"`. Users can roll out V3 inverted-index storage format to newly created partitions without changing historical partitions. - Test - [x] Regression test - [x] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need to test or manual test. Explain why: - [ ] This is a refactor/code format and no logic has been changed. - [ ] Previous test can cover this change. - [ ] No code files have been changed. - [ ] Other reason Test summary: - `./run-fe-ut.sh --run org.apache.doris.catalog.TablePropertyTest,org.apache.doris.common.PropertyAnalyzerTest` passed. - `DISABLE_BUILD_UI=ON ./build.sh --fe` passed, including FE Checkstyle and packaging. - `./run-regression-test.sh --run -d inverted_index_p0 -s test_partition_inverted_index_storage_format_rollout` passed. It covers initial, manual, auto, and dynamic partitions, `SHOW PARTITION`, and actual BE tablet meta headers. - `./run-regression-test.sh --run -d inverted_index_p2 -s test_partition_inverted_index_storage_format_replica_recovery` passed. It verifies that recovery recreates a removed V2 replica as V2 while a V3 partition remains V3. - Cloud regression test test_nereids_showpartitionid passed against the persistent Cloud runtime; Docker suites were not run. - Behavior changed: - [ ] No. - [x] Yes. Future partitions can use a different inverted-index storage format from historical partitions. - Does this need documentation? - [x] No. - [ ] Yes. - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label

hello-stephen · 2026-07-26T06:13:01Z

TPC-H: Total hot run time: 29829 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpch-tools
Tpch sf100 test result on commit bbfe84bf5587cb5c9a50e6c615d8781c818e258d, data reload: false

------ Round 1 ----------------------------------
============================================
q1	17703	4077	4071	4071
q2	2018	329	206	206
q3	10302	1455	864	864
q4	4678	471	345	345
q5	7516	843	548	548
q6	181	171	138	138
q7	747	834	610	610
q8	9312	1555	1610	1555
q9	5564	4384	4355	4355
q10	6750	1729	1517	1517
q11	507	383	341	341
q12	735	594	460	460
q13	18089	3338	2750	2750
q14	274	265	238	238
q15	q16	782	770	709	709
q17	920	917	902	902
q18	7012	5821	5647	5647
q19	1227	1352	1145	1145
q20	787	656	583	583
q21	5776	2666	2539	2539
q22	439	357	306	306
Total cold run time: 101319 ms
Total hot run time: 29829 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	4378	4324	4337	4324
q2	300	322	218	218
q3	4604	4963	4390	4390
q4	2057	2176	1367	1367
q5	4355	4270	4326	4270
q6	235	175	127	127
q7	1739	1749	1923	1749
q8	2598	2197	2206	2197
q9	8306	8017	7825	7825
q10	4678	4630	4188	4188
q11	569	414	423	414
q12	760	758	542	542
q13	3276	3737	2933	2933
q14	302	334	271	271
q15	q16	730	735	651	651
q17	1358	1370	1309	1309
q18	8048	7303	7229	7229
q19	1153	1118	1071	1071
q20	2221	2237	1929	1929
q21	5226	4604	4405	4405
q22	510	464	396	396
Total cold run time: 57403 ms
Total hot run time: 51805 ms

hello-stephen · 2026-07-26T06:24:15Z

TPC-DS: Total hot run time: 177980 ms

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/tpcds-tools
TPC-DS sf100 test result on commit bbfe84bf5587cb5c9a50e6c615d8781c818e258d, data reload: false

query5	4376	629	484	484
query6	462	214	199	199
query7	5011	564	352	352
query8	346	192	174	174
query9	8734	4005	4009	4005
query10	461	363	320	320
query11	5899	2313	2097	2097
query12	153	101	100	100
query13	1295	565	429	429
query14	6269	5188	4851	4851
query14_1	4207	4236	4174	4174
query15	210	206	176	176
query16	962	441	424	424
query17	925	705	543	543
query18	2410	468	327	327
query19	216	181	142	142
query20	112	104	105	104
query21	230	155	138	138
query22	13571	13461	13339	13339
query23	17366	16550	16116	16116
query23_1	16248	16182	16210	16182
query24	7504	1761	1267	1267
query24_1	1302	1283	1261	1261
query25	537	463	361	361
query26	1319	345	205	205
query27	2646	593	381	381
query28	4490	2008	1992	1992
query29	1040	613	467	467
query30	339	264	245	245
query31	1113	1087	992	992
query32	109	60	60	60
query33	537	308	253	253
query34	1177	1129	655	655
query35	753	777	651	651
query36	1171	1180	1036	1036
query37	157	103	87	87
query38	1874	1700	1625	1625
query39	878	871	846	846
query39_1	837	879	841	841
query40	241	164	138	138
query41	63	61	63	61
query42	96	87	90	87
query43	314	326	280	280
query44	1407	757	757	757
query45	190	181	176	176
query46	1066	1221	693	693
query47	2199	2093	2001	2001
query48	399	423	300	300
query49	574	430	329	329
query50	1088	454	336	336
query51	10787	11076	10963	10963
query52	87	92	75	75
query53	264	277	207	207
query54	303	265	230	230
query55	77	75	67	67
query56	330	317	307	307
query57	1335	1285	1179	1179
query58	300	279	266	266
query59	1569	1653	1451	1451
query60	310	284	275	275
query61	180	185	168	168
query62	558	502	427	427
query63	251	208	205	205
query64	2961	1171	983	983
query65	4719	4675	4631	4631
query66	1855	518	394	394
query67	29266	29188	29050	29050
query68	3123	1555	970	970
query69	412	311	285	285
query70	1075	955	956	955
query71	394	356	321	321
query72	3116	2694	2419	2419
query73	838	761	421	421
query74	5034	4926	4706	4706
query75	2508	2484	2141	2141
query76	2364	1162	754	754
query77	346	373	278	278
query78	11782	11861	11363	11363
query79	1376	1128	737	737
query80	1309	533	459	459
query81	567	333	287	287
query82	616	158	117	117
query83	397	325	306	306
query84	340	159	135	135
query85	975	610	548	548
query86	419	282	274	274
query87	1814	1834	1743	1743
query88	3703	2788	2763	2763
query89	432	381	326	326
query90	1951	196	202	196
query91	201	186	161	161
query92	63	59	57	57
query93	1679	1563	992	992
query94	720	332	311	311
query95	790	502	551	502
query96	1037	781	354	354
query97	2608	2681	2497	2497
query98	221	224	204	204
query99	1089	1114	975	975
Total cold run time: 263752 ms
Total hot run time: 177980 ms

hello-stephen · 2026-07-26T06:26:32Z

FE UT Coverage Report

Increment line coverage 61.00% (158/259) 🎉
Increment coverage report
Complete coverage report

hello-stephen · 2026-07-26T06:29:15Z

ClickBench: Total hot run time: 25.08 s

machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
scripts: https://github.com/apache/doris/tree/master/tools/clickbench-tools
ClickBench test result on commit bbfe84bf5587cb5c9a50e6c615d8781c818e258d, data reload: false

query1	0.00	0.01	0.00
query2	0.09	0.04	0.04
query3	0.24	0.14	0.14
query4	1.60	0.14	0.15
query5	0.23	0.22	0.23
query6	1.24	1.11	1.07
query7	0.04	0.00	0.00
query8	0.05	0.04	0.03
query9	0.37	0.32	0.32
query10	0.56	0.54	0.58
query11	0.19	0.14	0.13
query12	0.17	0.14	0.14
query13	0.47	0.48	0.47
query14	1.00	1.02	1.01
query15	0.62	0.58	0.60
query16	0.33	0.32	0.33
query17	1.14	1.12	1.11
query18	0.21	0.21	0.20
query19	2.06	1.96	1.92
query20	0.01	0.01	0.01
query21	15.44	0.19	0.15
query22	5.01	0.05	0.05
query23	16.14	0.31	0.12
query24	2.92	0.41	0.30
query25	0.11	0.05	0.05
query26	0.79	0.22	0.14
query27	0.05	0.04	0.03
query28	3.49	0.94	0.54
query29	12.47	4.13	3.33
query30	0.26	0.15	0.15
query31	2.76	0.59	0.31
query32	3.21	0.59	0.50
query33	3.17	3.13	3.24
query34	15.64	4.25	3.54
query35	3.59	3.58	3.53
query36	0.57	0.44	0.43
query37	0.08	0.07	0.06
query38	0.05	0.04	0.04
query39	0.04	0.03	0.03
query40	0.17	0.17	0.16
query41	0.09	0.04	0.03
query42	0.04	0.03	0.03
query43	0.04	0.04	0.04
Total cold run time: 96.75 s
Total hot run time: 25.08 s

hoshinojyunn requested review from 924060929, CalvinKirs, dataroaring, deardeng, englefly, gavinchou, luwei16, morningman, morrySnow, mymeiyi and starocean999 as code owners July 24, 2026 12:02

hoshinojyunn force-pushed the partition_upgrade branch 2 times, most recently from b28406e to 21fda6a Compare July 25, 2026 06:02

hoshinojyunn force-pushed the partition_upgrade branch 3 times, most recently from 9b34ab8 to bbfe84b Compare July 26, 2026 04:21

hoshinojyunn force-pushed the partition_upgrade branch from bbfe84b to 4590c76 Compare July 26, 2026 06:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[feat](fe) Support rolling upgrades of partition inverted index formats#66017

[feat](fe) Support rolling upgrades of partition inverted index formats#66017
hoshinojyunn wants to merge 1 commit into
apache:masterfrom
hoshinojyunn:partition_upgrade

hoshinojyunn commented Jul 24, 2026 •

edited

Loading

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hoshinojyunn commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

hoshinojyunn commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What problem does this PR solve?

Cloud mode support and validation

Release note

Check List (For Author)

Check List (For Reviewer who merge this PR)

Additional Cloud lifecycle support

Additional Cloud schema-version handling

Uh oh!

hello-stephen commented Jul 24, 2026

Uh oh!

hoshinojyunn commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

hello-stephen commented Jul 26, 2026

FE UT Coverage Report

Uh oh!

hello-stephen commented Jul 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

hoshinojyunn commented Jul 24, 2026 •

edited

Loading