[feature](fe) Add constraint-based colocate join inference with distribution mappings

[nooneuse]

What problem does this PR solve?

Problem Summary:

Doris can currently use Colocate Join when the join equality conditions directly cover all Hash distribution keys of two tables in the same stable Colocate Group.

However, some data models contain determinant columns that consistently map to distribution keys across tables. For example, if both tables are distributed by tenant_id, and each user_id always belongs to exactly one tenant_id, joining the tables by user_id is also colocated when the mapping from user_id to tenant_id is consistent across both tables.

Previously, Doris could not declare or use this cross-table mapping relationship. Such queries therefore required Shuffle Join even though matching rows were already located in corresponding Buckets.

This PR introduces a COLOCATE MAPPING constraint and allows Nereids to use the declared mapping when proving that a Join can run as a Colocate Join.

The implementation supports:

• A mapping determinant covering one or more ordered distribution-key positions.
• Multiple mappings jointly covering a composite distribution key.
• A combination of direct distribution-key equalities and mapping-derived coverage.
• Additional equality predicates that do not affect an already complete colocate proof.
• Conservative propagation through Project and supported ordinary non-DISTINCT Aggregate plans when the underlying natural Bucket locality remains valid, even if the final output removes original distribution-key columns.
• Conservative invalidation across runtime placement barriers that cannot truthfully preserve the original storage Bucket-to-task locality.
• Automatic fallback to another valid join distribution strategy, such as Shuffle Join or Broadcast Join, when a mapping proof is unavailable.
• Table-local metadata persistence and ADD, DROP, and SHOW lifecycle management for the new constraint.

The optimization is controlled by the session variable:

SET enable_colocate_mapping_constraint = true;

It is disabled by default. When disabled, scan distribution properties, join property requests, and Colocate Join decisions retain their original behavior.

The constraint is declared as NOT ENFORCED. Doris trusts the mapping supplied by the user and does not validate it during INSERT, UPDATE, load, compaction, or schema change. Declaring an incorrect mapping may produce incorrect query results when the optimization is enabled.

The mapping metadata is supported only for internal, non-temporary OLAP tables with Hash distribution. It is stored in the physical OlapTable object rather than in the global name-keyed constraint index. This keeps lifecycle behavior aligned with physical table ownership and avoids adding mapping-specific repair logic to external Catalog, HMS event, Rename, Replace, Recover, and recycle-bin paths.

This change is implemented entirely in FE. It reuses the existing Colocate Hash Join execution path and does not change BE Hash Join semantics or add FE-BE protocol fields.

Release note

Added an experimental COLOCATE MAPPING constraint that allows Nereids to derive Colocate Join eligibility from user-declared mappings between join columns and Hash distribution keys. Mapping-enabled queries fall back to ordinary distribution planning when a valid locality proof is unavailable. DISTINCT/MultiDistinct and pure deduplication Aggregates do not propagate mapping proofs, while ordinary non-DISTINCT Aggregates remain supported under conservative proof conditions. Atomic Restore rejects a selected table when its backup metadata contains mappings; use a non-atomic Restore or create a backup without mappings.

Applicable Scenarios

This feature is useful when:

• Tables are in the same stable Colocate Group.
• Tables use compatible single-column or composite Hash distribution layouts.
• Business-key columns consistently determine one or more distribution-key positions across the involved tables.
• Queries commonly join by those business keys rather than directly by every distribution key.

A typical example is:

user_id -> tenant_id

where both tables are distributed by tenant_id, but queries frequently join by user_id.

This feature should only be used when the declared mapping has identical semantics across every participating table. The mapping ID, determinant order, and target distribution-key positions are part of that cross-table contract.

Usage

Create two internal OLAP tables in the same Colocate Group:

CREATE TABLE orders (
    tenant_id BIGINT,
    user_id BIGINT,
    order_id BIGINT
)
DUPLICATE KEY(tenant_id, user_id)
DISTRIBUTED BY HASH(tenant_id) BUCKETS 16
PROPERTIES (
    "replication_num" = "1",
    "colocate_with" = "tenant_group"
);

CREATE TABLE users (
    tenant_id BIGINT,
    user_id BIGINT,
    user_name STRING
)
DUPLICATE KEY(tenant_id, user_id)
DISTRIBUTED BY HASH(tenant_id) BUCKETS 16
PROPERTIES (
    "replication_num" = "1",
    "colocate_with" = "tenant_group"
);

Declare the same logical mapping on both tables:

ALTER TABLE orders
ADD CONSTRAINT orders_user_mapping
COLOCATE MAPPING tenant_by_user (user_id)
DETERMINES DISTRIBUTION KEY (tenant_id)
NOT ENFORCED;

ALTER TABLE users
ADD CONSTRAINT users_user_mapping
COLOCATE MAPPING tenant_by_user (user_id)
DETERMINES DISTRIBUTION KEY (tenant_id)
NOT ENFORCED;

The constraint name is table-local, while the mapping identifier must match across tables:

Constraint names: orders_user_mapping, users_user_mapping
Mapping identifier: tenant_by_user

Enable the optimization:

SET enable_colocate_mapping_constraint = true;

A Join using the determinant columns can then use Colocate Join:

SELECT *
FROM orders o
JOIN users u
  ON o.user_id = u.user_id;

Use EXPLAIN to verify the selected distribution strategy:

EXPLAIN
SELECT *
FROM orders o
JOIN users u
  ON o.user_id = u.user_id;

The plan should contain:

INNER JOIN(COLOCATE)

The constraints can be removed with:

ALTER TABLE orders
DROP CONSTRAINT orders_user_mapping;

ALTER TABLE users
DROP CONSTRAINT users_user_mapping;

Metadata Lifecycle and Operational Behavior

A COLOCATE MAPPING constraint is stored as a complete JSON snapshot under the reserved __distribution_mapping_constraints key in the TableProperty.properties map owned by its OlapTable. It is not inserted into the global, qualified-name-keyed ConstraintManager.constraintsMap used by PRIMARY KEY, FOREIGN KEY, and UNIQUE constraints.

This table-local ownership defines the lifecycle behavior:

• Renaming a table preserves the same physical table object and therefore preserves its mappings without rewriting a secondary name index.
• Renaming or recovering a database preserves its table objects and their mappings.
• TRUNCATE TABLE preserves the table object and table properties, so mappings remain present after the partitions are replaced.
• A non-force table or database Drop keeps the physical object in the recycle bin. Recovering that object restores the same mappings.
• Creating a new table with the same name as a dropped table creates a different physical object and does not inherit mappings from the recycled object.
• During REPLACE TABLE ... PROPERTIES("swap"="false"), the replacement table object takes the target name and keeps the replacement object's mappings. The replaced object and its mappings follow the normal replacement lifecycle.
• During REPLACE TABLE ... PROPERTIES("swap"="true"), the two physical table objects exchange names while each object's mappings remain attached to that object.
• Backup copies the OlapTable metadata, including mappings.
• A non-atomic Restore of a selected table whose backup metadata contains mappings validates FE-version and schema compatibility before changing target-table state or creating replicas.
• Atomic Restore rejects a selected table whose backup metadata contains mappings. It is rejected before the destination table enters in_atomic_restore, before staging metadata is prepared, and before replicas are created, even when the destination currently has no conflicting constraint. Use a non-atomic Restore or create a backup without mappings.
• Atomic Restore when none of the selected backup tables contains mappings keeps the existing whole-table replacement semantics. Mappings that exist only on the current destination table do not survive a successful replacement.
• CREATE TABLE LIKE and CTAS create new physical table objects and do not copy mappings. A NOT ENFORCED business invariant cannot be inferred from schema similarity.

ADD binds each determinant and target distribution column to its current name, type, stable column unique ID, and base schema version. Planning and non-atomic Restore revalidate that binding before consuming the mapping. Query planning ignores an incompatible mapping and falls back to the ordinary distribution alternatives, while non-atomic Restore rejects it before changing target state. This prevents a same-name replacement column or an incompatible replayed schema change from silently producing a stale proof.

The following operations are rejected when they directly affect a determinant or target distribution column referenced by a mapping:

• DROP COLUMN.
• RENAME COLUMN.
• MODIFY COLUMN.
• Converting the table from Hash distribution to Random distribution.

For legacy tables whose referenced columns do not have stable column unique IDs, a base schema-version change invalidates the mapping conservatively. Drop and recreate the mapping after completing the schema change.

ADD and DROP use database read lock -> table write lock -> ConstraintManager lock ordering. The in-memory mutation and journal submission occur while metadata is protected. The journal await() runs only after database, table, and manager locks have been released.

While a table is participating in an Atomic Restore, both Mapping ADD and Mapping DROP are rejected by the normal ALTER-state fence. After cancellation, the fence is removed and the original table and mappings remain available. After successful replacement, the restored table owns exactly the mappings present in the backup; because selected backup tables containing mappings are rejected for Atomic Restore, the replacement table has no mappings.

Image persistence uses the reserved __distribution_mapping_constraints entry in the existing TableProperty.properties map. Each ADD or DROP serializes the complete mapping set in deterministic constraint-name order; dropping the final mapping persists [] instead of removing the key. The same one-entry properties map is journaled through the existing OP_MODIFY_TABLE_PROPERTIES envelope. An older FE can replay and checkpoint the opaque property without understanding the feature, while a supporting FE decodes the snapshot into its derived in-memory mapping map. Supporting FE versions do not publish these records as ordinary table-property binlogs.

SQL cache publication is disabled only after a Scan constructs at least one usable mapping proof. A table merely containing a mapping does not disable SQL cache when the session switch is off or when no proof is constructed. The feature changes physical distribution planning only and does not add mapping-specific MTMV rewrite-cache lifecycle hooks.

Rolling Upgrade Restrictions

Mapping ADD and a non-atomic Restore of selected tables whose backup metadata contains mappings require every registered FE to report the exact current version-shortHash. Query planning uses mappings only under the same condition; if an FE has not reported a version or reports a different version, the query ignores mappings and falls back to the ordinary distribution alternatives. Atomic Restore of such a table remains unsupported even after all FE versions converge.

The restrictions are:

• Do not create mappings or non-atomically restore selected tables whose backup metadata contains mappings until every registered FE has completed the upgrade and reports the same exact build as the current FE.
• The session switch does not need to be forcibly disabled during rolling upgrade. If mappings already exist and the switch is enabled, mixed or unknown FE versions cause query planning to ignore the mappings and use the original planning behavior.
• A schema-incompatible mapping is handled the same way during queries: all mappings on that table are ignored and a rate-limited warning identifies the table and stale constraint. ADD and non-atomic Restore remain strict.
• DROP remains available during mixed-version operation so mappings can be removed before downgrade or topology changes involving an unsupported FE, unless the table is currently fenced by an Atomic Restore.
• Adding a same-version FE does not require deleting mappings. ADD and non-atomic Restore of selected tables containing mappings remain unavailable until the new FE is registered and reports the exact current version; queries automatically resume mapping optimization after convergence.

Recommended rolling-upgrade sequence:

1. Upgrade every FE. Existing sessions may keep enable_colocate_mapping_constraint enabled; queries use ordinary planning while versions are mixed.
2. Confirm that all registered FEs report the same exact version-shortHash.
3. Create mappings or non-atomically restore selected tables containing mappings only after version convergence.
4. Existing mappings become eligible for optimization automatically after convergence.

Downgrading an FE to a version that does not implement this feature while mappings remain is unsupported. Drop all mappings with a supporting FE version before starting the downgrade.

External Catalog Constraint Consistency

COLOCATE MAPPING is deliberately unsupported for external Catalogs, HMS tables, RemoteOlapTable, and temporary tables. An ADD attempt on these table types fails instead of creating metadata that would need asynchronous reconciliation.

Consequently, this PR does not change external Catalog refresh, HMS notification, external Rename/Drop, connector event cursor, Catalog source-transition, or MTMV invalidation behavior. Existing PRIMARY KEY, FOREIGN KEY, and UNIQUE constraint behavior for external objects is unchanged by this feature.

This scope is intentional. External metadata can change outside Doris and is identified through Catalog-specific names, IDs, refreshes, and event streams. Supporting a user-trusted physical Bucket mapping there would require a separate identity, persistence, reconciliation, and failure model. Rejecting the feature at the DDL boundary avoids a large lifecycle patch surface unrelated to the core internal-OLAP optimization.

Limitations

• The constraint is NOT ENFORCED; Doris does not verify mapping consistency during writes.
• Mapping-based optimization applies only to the underlying natural Hash distribution of internal, non-temporary OLAP tables.
• Both inputs must have compatible Hash layouts and must satisfy the existing stable Colocate Group checks.
• Mapping IDs have cluster-local user-defined semantics. Doris checks the ID, determinant arity, target positions, schema binding, and Join equalities, but cannot verify that the business mapping is truthful.
• Determinant and target-column order is significant.
• Distribution target columns must be an ordered subset of the table's distribution columns.
• Mapping propagation is conservative across projections. Direct Slots, simple aliases, and non-truncating character widening casts are supported. Other expressions or casts discard the affected proof.
• Mapping locality is discarded across runtime placement barriers, including Generate/LATERAL VIEW, Window and PartitionTopN, Nested Loop Join, and Broadcast Hash Join. An outer Join falls back to another valid distribution strategy instead of reusing the original storage locality proof.
• A selected rollup must expose the required determinant provenance. A rollup that removes the determinant or cannot preserve a complete natural-layout proof does not use the mapping.
• Aggregate propagation is proof-based and conservative. Only ordinary non-DISTINCT Aggregates are supported, and only when their physical child still carries natural Bucket locality, Group By uses direct Slots, and direct distribution keys plus complete mapping determinants cover every distribution-key position.
• DISTINCT aggregate functions, MultiDistinct phases, and pure deduplication Aggregates do not request or propagate mapping properties. The query remains supported, but an upper Join cannot rely on a mapping proof across that boundary and retains the ordinary distribution alternatives.
• Repeat/Grouping Sets, expression-based Group By, aggregation after a non-natural redistribution, incomplete composite determinants, uncovered distribution-key positions, and outputs that remove determinants required by an upper Join do not propagate a usable mapping proof.
• Union, Intersect, Except, multi-hop mapping closure, mapping-closure inference, and expression-based determinants are not supported.
• A mapping requirement is non-enforceable. The optimizer cannot insert an Exchange to manufacture it or degrade it into a one-sided Bucket Shuffle.
• Atomic Restore of a selected table whose backup metadata contains COLOCATE MAPPING constraints is unsupported. Non-atomic Restore remains supported after FE-version and schema validation.

The following examples use orders and users distributed by tenant_id, with user_id declared as the determinant of tenant_id.

An ordinary Aggregate can preserve the mapping when the complete determinant covers the distribution-key position:

SELECT user_id, SUM(amount)
FROM orders
GROUP BY user_id;

A query containing a DISTINCT aggregate function remains executable, but the Aggregate is a mapping-proof barrier. An upper Join that would need the proof to cross this Aggregate therefore uses ordinary distribution planning:

SELECT user_id, COUNT(DISTINCT order_id)
FROM orders
GROUP BY user_id;

The same conservative fallback applies to MultiDistinct phases and pure deduplication such as SELECT DISTINCT user_id FROM orders. This boundary prevents a DISTINCT plan from incorrectly forwarding a locality proof derived for a different row grouping.

The following Aggregate shapes do not propagate a usable mapping proof:

-- Repeat/Grouping Sets can produce grouping rows that do not contain the determinant.
SELECT tenant_id, user_id, SUM(amount)
FROM orders
GROUP BY GROUPING SETS ((tenant_id, user_id), (tenant_id));

-- Expression-based Group By is not the declared direct-Slot determinant.
SELECT user_id + 0, SUM(amount)
FROM orders
GROUP BY user_id + 0;

For a table distributed by HASH(tenant_id, region_id), where only user_id -> tenant_id is declared, the following Group By leaves the region_id Bucket position uncovered:

SELECT user_id, SUM(amount)
FROM orders
GROUP BY user_id;

For a composite determinant (country_id, user_id) -> tenant_id, both determinant columns must be present in the proof. Joining or grouping only by user_id is insufficient.

An Aggregate may group by a determinant without returning it, but an upper Join cannot use that determinant after it has been removed from the Aggregate output:

SELECT *
FROM (
    SELECT SUM(amount) AS total_amount
    FROM orders
    GROUP BY user_id
) o
JOIN users u
  ON o.total_amount = u.user_id;

An Aggregate also does not propagate the mapping if its input has already been changed from the table's natural Bucket locality by an Exchange. For example, if the Join below requires Shuffle on region_id, the Aggregate above it cannot recover the original tenant_id Bucket locality:

SELECT o.tenant_id, o.user_id, SUM(o.amount)
FROM orders o
JOIN regions r ON o.region_id = r.region_id
GROUP BY o.tenant_id, o.user_id;

UNION ALL does not preserve mapping locality even when each input independently has a valid mapping:

SELECT user_id FROM current_orders
UNION ALL
SELECT user_id FROM archived_orders;

Multi-hop closure is not derived. Declaring or knowing email -> user_id and user_id -> tenant_id does not let Doris infer email -> tenant_id; a determinant must map directly to the distribution-key positions in a supported constraint.

Expression-based determinants are not accepted. For example, the following conceptual declaration is unsupported; determinants must be column Slots:

COLOCATE MAPPING tenant_by_email (LOWER(email))
DETERMINES DISTRIBUTION KEY (tenant_id)
NOT ENFORCED

Upgrade and compatibility considerations

Mapping metadata is encoded for backward readability:

• The complete mapping set is serialized as JSON in the reserved __distribution_mapping_constraints entry of the TableProperty.properties map owned by the OlapTable, separate from the global polymorphic constraint map.
• ADD and DROP rewrite that complete snapshot and reuse the existing OP_MODIFY_TABLE_PROPERTIES journal record. The final DROP writes [], so replay and checkpoint cannot resurrect an older mapping set.
• An older FE treats the entry as an opaque table property and preserves it through journal replay and image checkpoint. A supporting FE recognizes the key, rebuilds the derived mapping map, and skips ordinary table-property binlog publication for these records.

Backward readability prevents an older FE from failing merely because an image or journal contains the reserved property and preserves the opaque snapshot across checkpoint. It does not make the feature supported on that FE: an older FE cannot show or use mappings and does not enforce mapping-specific DDL safeguards.

The exact-version gate therefore remains required:

• Do not execute Mapping ADD or non-atomic Restore of selected tables containing mappings until all registered FEs report the exact current build.
• A missing reported version fails the ADD/non-atomic-Restore gate and makes queries fall back to ordinary planning.
• The gate compares reported version strings; it is not a capability-negotiation protocol. Custom binaries that report the same version string remain the operator's responsibility.
• Avoid changing FE membership concurrently with Mapping ADD or non-atomic Restore of selected tables containing mappings. Complete the membership change, wait for the FE to appear and report its version, and then retry the operation.
• Atomic Restore of a selected table containing mappings is rejected independently of this version gate.

Required downgrade procedure:

1. Stop enabling enable_colocate_mapping_constraint.
2. DROP all COLOCATE MAPPING constraints while a supporting FE version is still running.
3. Confirm cleanup with SHOW CONSTRAINTS on the affected tables.
4. Start the FE downgrade only after cleanup.

Do not complete a downgrade while mappings remain. Although an unsupported FE preserves the opaque snapshot, it cannot use or manage the feature and does not enforce mapping-specific DDL safeguards.

The same rules apply in Cloud mode. Wait until every expected FE is visible in the registered FE set and reports the exact current build before Mapping ADD or non-atomic Restore of selected tables containing mappings. Mapping-enabled queries fall back to ordinary planning while versions are mixed and resume the optimization after convergence. DROP remains the recovery path when versions are mixed, except while a table is fenced by an Atomic Restore.

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

• Behavior changed:

  • No.
  • Yes. Adds the experimental COLOCATE MAPPING constraint and mapping-based Colocate Join inference for internal OLAP tables. The planner optimization is disabled by default and falls back to ordinary planning when its proof is unavailable, crosses a DISTINCT/MultiDistinct/pure-deduplication Aggregate, or crosses another unsupported runtime placement barrier. Atomic Restore rejects selected tables whose backup metadata contains mappings; non-atomic Restore remains supported after compatibility validation.

• 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

[hello-stephen]

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:

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

[nooneuse]

run buildall

[hello-stephen]

TPC-H: Total hot run time: 29764 ms

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

------ Round 1 ----------------------------------
============================================
q1	17598	4108	4087	4087
q2	2040	333	201	201
q3	10246	1438	817	817
q4	4687	470	339	339
q5	7490	865	588	588
q6	179	172	135	135
q7	770	830	614	614
q8	9360	1678	1631	1631
q9	5643	4335	4320	4320
q10	6734	1745	1480	1480
q11	526	353	336	336
q12	723	581	456	456
q13	18169	3417	2787	2787
q14	263	272	237	237
q15	q16	789	776	703	703
q17	1038	937	1023	937
q18	7298	5649	5490	5490
q19	1332	1322	1044	1044
q20	802	705	565	565
q21	6394	2929	2663	2663
q22	477	368	334	334
Total cold run time: 102558 ms
Total hot run time: 29764 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	5211	4872	4802	4802
q2	300	376	207	207
q3	4930	5310	4702	4702
q4	2098	2162	1381	1381
q5	4975	4628	4771	4628
q6	228	178	128	128
q7	1905	1732	1593	1593
q8	2431	2095	2076	2076
q9	7558	7187	7167	7167
q10	4665	4547	4064	4064
q11	525	378	349	349
q12	735	737	521	521
q13	3011	3381	2761	2761
q14	268	280	247	247
q15	q16	681	691	605	605
q17	1276	1256	1248	1248
q18	7171	6771	6705	6705
q19	1094	1087	1084	1084
q20	2211	2199	1937	1937
q21	5263	4578	4383	4383
q22	503	441	401	401
Total cold run time: 57039 ms
Total hot run time: 50989 ms

[hello-stephen]

TPC-DS: Total hot run time: 178166 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 757e7cfff64d323f8c06de0fe1f0a365c9b6918b, data reload: false

query5	4322	632	491	491
query6	458	221	217	217
query7	4907	557	323	323
query8	336	191	174	174
query9	8823	4031	4030	4030
query10	460	356	301	301
query11	5902	2337	2109	2109
query12	170	101	101	101
query13	1249	582	436	436
query14	6235	5203	4868	4868
query14_1	4211	4194	4213	4194
query15	209	206	179	179
query16	1002	444	397	397
query17	912	714	585	585
query18	2448	475	356	356
query19	215	190	153	153
query20	114	106	107	106
query21	231	167	136	136
query22	13552	13605	13411	13411
query23	17423	16420	16040	16040
query23_1	16210	16187	16232	16187
query24	7508	1770	1293	1293
query24_1	1307	1273	1251	1251
query25	529	422	367	367
query26	1333	364	203	203
query27	2605	594	385	385
query28	4460	2027	2015	2015
query29	1056	616	466	466
query30	335	266	227	227
query31	1118	1084	977	977
query32	115	60	61	60
query33	500	313	251	251
query34	1183	1129	646	646
query35	767	775	660	660
query36	1037	1028	891	891
query37	156	103	94	94
query38	1888	1702	1650	1650
query39	884	866	869	866
query39_1	828	835	847	835
query40	248	171	142	142
query41	67	69	67	67
query42	92	93	92	92
query43	320	323	276	276
query44	1421	791	763	763
query45	193	190	170	170
query46	1090	1199	749	749
query47	2174	2086	1988	1988
query48	434	415	306	306
query49	600	425	308	308
query50	1069	439	352	352
query51	11146	10676	10899	10676
query52	91	89	82	82
query53	254	281	201	201
query54	297	267	231	231
query55	78	75	68	68
query56	313	315	328	315
query57	1326	1303	1221	1221
query58	314	274	268	268
query59	1569	1639	1460	1460
query60	305	286	275	275
query61	184	176	178	176
query62	552	500	439	439
query63	243	205	203	203
query64	2958	1165	997	997
query65	4755	4676	4627	4627
query66	1831	518	416	416
query67	29683	29282	29253	29253
query68	3109	1448	965	965
query69	480	301	267	267
query70	936	823	805	805
query71	381	337	334	334
query72	3103	2706	2362	2362
query73	878	814	448	448
query74	5102	4901	4716	4716
query75	2542	2509	2124	2124
query76	2310	1169	768	768
query77	353	369	290	290
query78	12126	11910	11387	11387
query79	1444	1186	778	778
query80	1290	560	485	485
query81	544	348	296	296
query82	601	155	119	119
query83	393	331	296	296
query84	325	160	135	135
query85	993	599	541	541
query86	417	238	237	237
query87	1852	1816	1761	1761
query88	3758	2852	2814	2814
query89	421	360	334	334
query90	1909	199	191	191
query91	201	201	168	168
query92	64	58	53	53
query93	1786	1486	1013	1013
query94	738	361	312	312
query95	809	485	468	468
query96	1038	786	340	340
query97	2625	2620	2496	2496
query98	217	206	207	206
query99	1095	1121	985	985
Total cold run time: 264711 ms
Total hot run time: 178166 ms

[hello-stephen]

ClickBench: Total hot run time: 24.91 s

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

query1	0.01	0.01	0.01
query2	0.10	0.05	0.04
query3	0.26	0.14	0.14
query4	1.60	0.14	0.14
query5	0.24	0.22	0.22
query6	1.16	0.81	0.80
query7	0.04	0.00	0.01
query8	0.06	0.04	0.04
query9	0.38	0.31	0.31
query10	0.54	0.53	0.56
query11	0.21	0.14	0.13
query12	0.18	0.15	0.15
query13	0.48	0.48	0.48
query14	1.02	1.00	1.04
query15	0.61	0.60	0.60
query16	0.31	0.31	0.31
query17	1.12	1.11	1.12
query18	0.24	0.21	0.21
query19	2.05	1.99	1.96
query20	0.01	0.01	0.02
query21	15.46	0.17	0.13
query22	5.06	0.05	0.05
query23	16.09	0.29	0.13
query24	3.01	0.44	0.32
query25	0.13	0.04	0.04
query26	0.71	0.21	0.14
query27	0.04	0.04	0.03
query28	3.56	0.92	0.54
query29	12.51	4.11	3.28
query30	0.26	0.16	0.16
query31	2.77	0.62	0.31
query32	3.22	0.58	0.48
query33	3.14	3.24	3.24
query34	15.55	4.25	3.53
query35	3.48	3.55	3.55
query36	0.55	0.45	0.44
query37	0.08	0.06	0.07
query38	0.05	0.03	0.04
query39	0.03	0.03	0.03
query40	0.19	0.15	0.14
query41	0.09	0.03	0.03
query42	0.04	0.03	0.03
query43	0.04	0.04	0.03
Total cold run time: 96.68 s
Total hot run time: 24.91 s

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 67.89% (167/246) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[hello-stephen]

TPC-H: Total hot run time: 30059 ms

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

------ Round 1 ----------------------------------
============================================
q1	17609	4233	4200	4200
q2	2065	328	209	209
q3	10222	1407	860	860
q4	4682	481	337	337
q5	7547	843	580	580
q6	194	184	139	139
q7	766	832	631	631
q8	9340	1585	1719	1585
q9	5558	4343	4370	4343
q10	6753	1772	1473	1473
q11	513	370	331	331
q12	759	581	451	451
q13	18148	3452	2751	2751
q14	270	264	241	241
q15	q16	780	780	711	711
q17	1012	1093	1023	1023
q18	6928	5865	5543	5543
q19	1328	1221	1079	1079
q20	821	707	645	645
q21	6414	2907	2613	2613
q22	463	387	314	314
Total cold run time: 102172 ms
Total hot run time: 30059 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	5363	5091	4963	4963
q2	309	331	223	223
q3	5035	5288	4688	4688
q4	2103	2166	1383	1383
q5	4940	4775	4661	4661
q6	237	182	157	157
q7	2009	1750	1571	1571
q8	2538	2187	2135	2135
q9	7619	7189	7228	7189
q10	4630	4572	4116	4116
q11	544	385	384	384
q12	760	743	528	528
q13	2973	3373	2797	2797
q14	271	271	266	266
q15	q16	680	697	619	619
q17	1315	1283	1286	1283
q18	7281	6952	6908	6908
q19	1097	1096	1082	1082
q20	2223	2182	1968	1968
q21	5323	4589	4567	4567
q22	521	479	403	403
Total cold run time: 57771 ms
Total hot run time: 51891 ms

[hello-stephen]

TPC-DS: Total hot run time: 178121 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 bea1155182f19ff154bd80d23af5ea1c694c6c7a, data reload: false

query5	4329	635	484	484
query6	488	223	219	219
query7	4847	643	343	343
query8	341	192	175	175
query9	8743	4129	4124	4124
query10	491	360	309	309
query11	5910	2326	2152	2152
query12	166	112	100	100
query13	1258	586	420	420
query14	6246	5203	4884	4884
query14_1	4215	4213	4229	4213
query15	210	205	177	177
query16	1006	495	435	435
query17	944	678	563	563
query18	2442	469	337	337
query19	207	184	147	147
query20	108	105	104	104
query21	237	159	134	134
query22	13599	13559	13309	13309
query23	17295	16553	16149	16149
query23_1	16124	16233	16169	16169
query24	7625	1752	1285	1285
query24_1	1294	1304	1309	1304
query25	538	433	367	367
query26	1328	369	215	215
query27	2598	605	399	399
query28	4502	2015	2042	2015
query29	1054	629	483	483
query30	344	266	236	236
query31	1123	1084	976	976
query32	109	60	56	56
query33	515	313	245	245
query34	1183	1116	656	656
query35	777	780	652	652
query36	1034	1032	886	886
query37	153	104	95	95
query38	1890	1684	1650	1650
query39	879	879	838	838
query39_1	827	820	836	820
query40	251	167	144	144
query41	65	65	64	64
query42	97	95	92	92
query43	329	334	291	291
query44	1511	798	781	781
query45	203	178	171	171
query46	1071	1251	720	720
query47	2150	2116	1968	1968
query48	349	383	294	294
query49	604	424	315	315
query50	1069	428	355	355
query51	11105	10921	10991	10921
query52	96	92	79	79
query53	268	292	205	205
query54	305	257	246	246
query55	79	75	70	70
query56	332	340	305	305
query57	1329	1290	1194	1194
query58	309	296	264	264
query59	1605	1646	1427	1427
query60	324	305	262	262
query61	183	177	175	175
query62	550	500	437	437
query63	246	206	208	206
query64	2945	1056	869	869
query65	4746	4610	4629	4610
query66	1844	514	382	382
query67	29264	29328	29146	29146
query68	2996	1583	1061	1061
query69	425	303	272	272
query70	932	855	798	798
query71	395	340	344	340
query72	3046	2690	2398	2398
query73	869	780	412	412
query74	5117	4919	4732	4732
query75	2523	2495	2124	2124
query76	2337	1219	811	811
query77	352	384	281	281
query78	11877	11784	11241	11241
query79	1383	1182	753	753
query80	669	561	469	469
query81	468	329	299	299
query82	593	156	122	122
query83	411	335	304	304
query84	329	163	135	135
query85	948	613	538	538
query86	336	255	228	228
query87	1821	1824	1739	1739
query88	3855	2867	2831	2831
query89	436	375	329	329
query90	1899	213	206	206
query91	207	198	167	167
query92	62	61	60	60
query93	1563	1466	1004	1004
query94	546	347	323	323
query95	796	601	496	496
query96	1119	786	369	369
query97	2643	2635	2476	2476
query98	216	211	203	203
query99	1095	1127	979	979
Total cold run time: 262936 ms
Total hot run time: 178121 ms

[hello-stephen]

ClickBench: Total hot run time: 24.8 s

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

query1	0.01	0.01	0.00
query2	0.10	0.04	0.04
query3	0.27	0.13	0.14
query4	1.61	0.14	0.14
query5	0.25	0.23	0.23
query6	1.16	0.82	0.83
query7	0.04	0.00	0.00
query8	0.06	0.04	0.04
query9	0.37	0.31	0.33
query10	0.59	0.56	0.58
query11	0.19	0.13	0.13
query12	0.18	0.14	0.15
query13	0.48	0.49	0.50
query14	1.03	1.02	0.99
query15	0.63	0.61	0.60
query16	0.31	0.32	0.32
query17	1.10	1.10	1.16
query18	0.24	0.22	0.21
query19	2.05	1.98	1.96
query20	0.01	0.01	0.02
query21	15.41	0.21	0.14
query22	4.93	0.05	0.06
query23	16.11	0.32	0.13
query24	2.92	0.42	0.33
query25	0.11	0.06	0.03
query26	0.72	0.20	0.16
query27	0.05	0.03	0.04
query28	3.50	0.86	0.53
query29	12.49	4.16	3.32
query30	0.27	0.17	0.15
query31	2.78	0.61	0.31
query32	3.22	0.60	0.49
query33	3.18	3.19	3.15
query34	15.50	4.17	3.51
query35	3.56	3.53	3.48
query36	0.56	0.43	0.43
query37	0.09	0.06	0.07
query38	0.04	0.04	0.03
query39	0.04	0.03	0.03
query40	0.18	0.15	0.14
query41	0.09	0.04	0.03
query42	0.04	0.02	0.02
query43	0.04	0.04	0.03
Total cold run time: 96.51 s
Total hot run time: 24.8 s

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 67.61% (167/247) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[hello-stephen]

TPC-H: Total hot run time: 28512 ms

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

------ Round 1 ----------------------------------
============================================
q1	18148	4049	4011	4011
q2	2452	315	192	192
q3	10709	1338	779	779
q4	4746	460	335	335
q5	8206	811	549	549
q6	189	171	131	131
q7	731	812	605	605
q8	10083	1391	1377	1377
q9	6912	4045	3980	3980
q10	7139	1597	1354	1354
q11	816	349	323	323
q12	982	580	448	448
q13	18777	3226	2752	2752
q14	268	249	233	233
q15	q16	745	724	657	657
q17	1051	971	989	971
q18	7324	5697	5587	5587
q19	1789	1215	1026	1026
q20	806	691	564	564
q21	5947	2618	2340	2340
q22	419	368	298	298
Total cold run time: 108239 ms
Total hot run time: 28512 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	4455	4310	4337	4310
q2	297	313	203	203
q3	4527	4902	4420	4420
q4	2170	2256	1407	1407
q5	4235	4383	4327	4327
q6	230	191	130	130
q7	1694	1626	1525	1525
q8	2236	2083	2126	2083
q9	7166	7017	7125	7017
q10	4295	4239	3837	3837
q11	588	410	388	388
q12	712	726	516	516
q13	3213	3558	2907	2907
q14	291	297	285	285
q15	q16	832	698	603	603
q17	1214	1204	1202	1202
q18	7233	6944	6884	6884
q19	1113	1074	1086	1074
q20	2224	2237	1920	1920
q21	5528	4925	4838	4838
q22	545	486	433	433
Total cold run time: 54798 ms
Total hot run time: 50309 ms

[hello-stephen]

TPC-DS: Total hot run time: 169891 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 c6503ad2fa10416b8061ca969623e01d43efd31a, data reload: false

query5	4386	602	471	471
query6	519	227	199	199
query7	5047	583	314	314
query8	620	189	171	171
query9	8773	4062	4034	4034
query10	473	362	289	289
query11	5878	2250	2006	2006
query12	163	102	99	99
query13	1257	597	441	441
query14	6288	4844	4491	4491
query14_1	3957	3952	3897	3897
query15	217	199	174	174
query16	3595	487	435	435
query17	1183	699	567	567
query18	2534	454	350	350
query19	241	209	153	153
query20	114	101	101	101
query21	788	164	141	141
query22	13153	13032	12876	12876
query23	17286	16882	16110	16110
query23_1	16277	16291	16134	16134
query24	8310	1795	1276	1276
query24_1	1317	1298	1258	1258
query25	564	427	391	391
query26	1392	359	220	220
query27	3014	605	350	350
query28	4457	2017	1996	1996
query29	1093	586	455	455
query30	492	253	225	225
query31	1101	1067	953	953
query32	113	57	57	57
query33	540	338	233	233
query34	1227	1109	635	635
query35	713	758	629	629
query36	795	785	722	722
query37	150	100	81	81
query38	1897	1648	1586	1586
query39	848	813	803	803
query39_1	782	776	809	776
query40	320	157	139	139
query41	65	58	60	58
query42	95	89	87	87
query43	307	321	275	275
query44	1450	754	755	754
query45	185	171	163	163
query46	1040	1189	698	698
query47	1542	1490	1454	1454
query48	415	403	281	281
query49	638	391	288	288
query50	1011	435	346	346
query51	10580	10791	10231	10231
query52	83	84	75	75
query53	253	267	203	203
query54	325	232	217	217
query55	71	73	65	65
query56	294	302	272	272
query57	1381	991	899	899
query58	325	269	265	265
query59	1543	1630	1396	1396
query60	350	274	244	244
query61	153	157	185	157
query62	486	323	267	267
query63	232	191	195	191
query64	2487	1016	852	852
query65	3900	3850	3868	3850
query66	1743	445	357	357
query67	28325	28170	28165	28165
query68	3164	1556	959	959
query69	604	301	249	249
query70	914	793	784	784
query71	382	352	300	300
query72	3343	2701	2485	2485
query73	897	780	453	453
query74	4681	4496	4322	4322
query75	2399	2339	2030	2030
query76	1915	1131	724	724
query77	361	382	280	280
query78	11269	11212	10667	10667
query79	1381	1223	764	764
query80	729	572	485	485
query81	641	333	294	294
query82	652	155	125	125
query83	413	349	312	312
query84	436	167	136	136
query85	1312	693	521	521
query86	512	241	231	231
query87	1807	1785	1696	1696
query88	3802	2795	2780	2780
query89	417	307	276	276
query90	1939	213	194	194
query91	198	192	165	165
query92	61	59	51	51
query93	1677	1461	1004	1004
query94	591	353	294	294
query95	799	507	494	494
query96	996	802	365	365
query97	2443	2469	2349	2349
query98	213	195	190	190
query99	831	721	603	603
Total cold run time: 264597 ms
Total hot run time: 169891 ms

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 72.53% (198/273) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[hello-stephen]

TPC-H: Total hot run time: 29137 ms

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

------ Round 1 ----------------------------------
============================================
q1	17833	3967	3964	3964
q2	2021	323	205	205
q3	10302	1438	805	805
q4	4680	478	344	344
q5	7502	864	564	564
q6	186	176	141	141
q7	740	812	606	606
q8	9366	1580	1566	1566
q9	5362	4080	4051	4051
q10	6790	1640	1362	1362
q11	499	370	335	335
q12	724	580	452	452
q13	18088	3298	2665	2665
q14	266	257	237	237
q15	q16	745	728	658	658
q17	1013	993	1079	993
q18	6768	5805	5597	5597
q19	1169	1344	1013	1013
q20	812	698	560	560
q21	6044	2832	2692	2692
q22	461	387	327	327
Total cold run time: 101371 ms
Total hot run time: 29137 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	4944	4664	4606	4606
q2	286	325	214	214
q3	4884	5241	4665	4665
q4	2185	2277	1430	1430
q5	4525	4562	4442	4442
q6	229	175	131	131
q7	1810	1819	1495	1495
q8	2341	2057	2032	2032
q9	7186	6972	6730	6730
q10	4249	4198	3807	3807
q11	509	374	340	340
q12	691	711	496	496
q13	3019	3242	2763	2763
q14	267	276	251	251
q15	q16	664	689	620	620
q17	1223	1236	1207	1207
q18	7391	6608	6670	6608
q19	1040	1073	1048	1048
q20	2197	2193	1926	1926
q21	5252	4589	4426	4426
q22	521	458	414	414
Total cold run time: 55413 ms
Total hot run time: 49651 ms

[hello-stephen]

FE UT Coverage Report

Increment line coverage 61.32% (176/287) 🎉
Increment coverage report
Complete coverage report

[hello-stephen]

TPC-H: Total hot run time: 28673 ms

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

------ Round 1 ----------------------------------
============================================
q1	17660	4052	3931	3931
q2	1996	335	201	201
q3	10315	1366	806	806
q4	4680	471	335	335
q5	7504	815	559	559
q6	186	164	134	134
q7	721	795	600	600
q8	9869	1605	1556	1556
q9	5790	4032	4017	4017
q10	6776	1621	1353	1353
q11	510	396	311	311
q12	741	574	451	451
q13	18105	3249	2771	2771
q14	272	265	253	253
q15	q16	728	710	659	659
q17	1499	1120	750	750
q18	6985	5688	5428	5428
q19	2089	1222	1061	1061
q20	784	672	582	582
q21	6185	2825	2610	2610
q22	451	370	305	305
Total cold run time: 103846 ms
Total hot run time: 28673 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	4796	4512	4497	4497
q2	432	319	207	207
q3	4885	5148	4803	4803
q4	2139	2278	1432	1432
q5	4649	4493	4481	4481
q6	228	171	130	130
q7	1879	1710	1511	1511
q8	2263	1869	1836	1836
q9	6743	6758	6729	6729
q10	4224	4222	3775	3775
q11	517	365	336	336
q12	702	713	489	489
q13	3005	3291	2722	2722
q14	273	284	253	253
q15	q16	655	691	608	608
q17	1247	1213	1215	1213
q18	7315	6661	6700	6661
q19	1090	1043	1043	1043
q20	2184	2195	1911	1911
q21	5294	4584	4365	4365
q22	533	456	401	401
Total cold run time: 55053 ms
Total hot run time: 49403 ms

[hello-stephen]

TPC-DS: Total hot run time: 169918 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 bd2da7e2ec841c5a0c3d6b3d16499ad5a3f67a73, data reload: false

query5	4340	629	452	452
query6	460	228	212	212
query7	4881	583	342	342
query8	337	183	163	163
query9	8764	4041	4039	4039
query10	476	345	298	298
query11	5807	2205	2061	2061
query12	152	98	102	98
query13	1270	600	415	415
query14	6115	4712	4403	4403
query14_1	3769	3768	3765	3765
query15	206	197	170	170
query16	1033	464	435	435
query17	1094	690	536	536
query18	2418	456	369	369
query19	214	189	151	151
query20	110	102	103	102
query21	228	162	139	139
query22	12998	12989	12920	12920
query23	17292	16289	15999	15999
query23_1	16219	16061	16065	16061
query24	7457	1661	1228	1228
query24_1	1231	1245	1207	1207
query25	565	456	356	356
query26	1344	360	211	211
query27	2627	612	377	377
query28	4491	2021	2068	2021
query29	1328	606	469	469
query30	340	254	226	226
query31	1101	1070	945	945
query32	114	63	61	61
query33	553	323	252	252
query34	1181	1184	662	662
query35	757	774	647	647
query36	787	785	716	716
query37	154	102	90	90
query38	1879	1719	1617	1617
query39	841	818	800	800
query39_1	777	804	775	775
query40	246	178	139	139
query41	66	63	67	63
query42	94	90	89	89
query43	314	321	278	278
query44	1413	789	768	768
query45	187	173	163	163
query46	1076	1165	717	717
query47	1529	1509	1466	1466
query48	411	408	288	288
query49	583	416	287	287
query50	1119	423	329	329
query51	10387	11201	10668	10668
query52	86	87	74	74
query53	258	287	200	200
query54	286	222	236	222
query55	71	69	64	64
query56	307	283	279	279
query57	1012	980	951	951
query58	278	279	266	266
query59	1491	1593	1367	1367
query60	302	269	245	245
query61	151	155	155	155
query62	391	329	266	266
query63	233	200	194	194
query64	2810	1021	860	860
query65	3884	3834	3814	3814
query66	1840	457	383	383
query67	28579	28284	28133	28133
query68	3306	1602	1050	1050
query69	410	302	262	262
query70	860	786	763	763
query71	383	336	338	336
query72	3145	2811	2494	2494
query73	876	757	423	423
query74	4602	4524	4314	4314
query75	2401	2335	2003	2003
query76	2346	1125	753	753
query77	350	379	288	288
query78	11100	11215	10579	10579
query79	1371	1137	753	753
query80	1297	563	485	485
query81	557	333	286	286
query82	599	152	118	118
query83	369	318	289	289
query84	276	159	131	131
query85	963	612	526	526
query86	403	239	224	224
query87	1812	1831	1717	1717
query88	3727	2819	2811	2811
query89	396	331	278	278
query90	1910	197	187	187
query91	200	195	165	165
query92	60	58	54	54
query93	1684	1561	1015	1015
query94	727	339	313	313
query95	775	592	495	495
query96	1076	852	375	375
query97	2452	2452	2353	2353
query98	210	198	190	190
query99	714	721	605	605
Total cold run time: 256627 ms
Total hot run time: 169918 ms

[hello-stephen]

TPC-H: Total hot run time: 16834 ms

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

------ Round 1 ----------------------------------
============================================
q1	17571	3042	3020	3020
q2	2088	265	237	237
q3	10235	885	513	513
q4	4674	259	205	205
q5	7669	556	394	394
q6	138	114	95	95
q7	541	501	382	382
q8	9243	895	947	895
q9	3483	2446	2421	2421
q10	6485	850	701	701
q11	386	199	176	176
q12	610	261	202	202
q13	18177	1530	1164	1164
q14	154	147	135	135
q15	q16	430	391	365	365
q17	1344	850	810	810
q18	3013	2235	2246	2235
q19	1098	925	795	795
q20	367	281	201	201
q21	4872	1661	1965	1661
q22	318	275	227	227
Total cold run time: 92896 ms
Total hot run time: 16834 ms

----- Round 2, with runtime_filter_mode=off -----
============================================
q1	3372	3368	3339	3339
q2	499	393	365	365
q3	2226	2298	2148	2148
q4	1180	1155	891	891
q5	2143	2114	2082	2082
q6	172	115	87	87
q7	1050	919	854	854
q8	1576	1390	1414	1390
q9	3095	3089	3062	3062
q10	1850	1807	1602	1602
q11	352	269	244	244
q12	449	433	345	345
q13	1476	1550	1160	1160
q14	173	168	160	160
q15	q16	400	397	353	353
q17	3594	3378	3310	3310
q18	4849	4399	4765	4399
q19	879	845	873	845
q20	1056	994	830	830
q21	3841	3105	3284	3105
q22	382	339	326	326
Total cold run time: 34614 ms
Total hot run time: 30897 ms

[hello-stephen]

TPC-DS: Total hot run time: 81542 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 3014400b6780d01fa2fe2b726555ccad4f42bb14, data reload: false

query5	4265	417	328	328
query6	378	135	121	121
query7	4972	416	233	233
query8	291	118	131	118
query9	8681	2871	2860	2860
query10	382	215	178	178
query11	5367	1047	909	909
query12	111	71	70	70
query13	1187	453	315	315
query14	6100	2190	2076	2076
query14_1	1958	1939	1940	1939
query15	174	116	117	116
query16	928	368	347	347
query17	801	462	363	363
query18	2320	327	239	239
query19	164	140	108	108
query20	80	70	70	70
query21	206	101	87	87
query22	5309	5352	5304	5304
query23	6678	6221	5892	5892
query23_1	6035	6030	5900	5900
query24	7296	1104	757	757
query24_1	761	760	794	760
query25	431	317	270	270
query26	1235	223	125	125
query27	2811	430	264	264
query28	4681	1489	1506	1489
query29	939	457	360	360
query30	251	147	130	130
query31	829	399	331	331
query32	126	73	75	73
query33	464	231	181	181
query34	991	833	504	504
query35	407	409	348	348
query36	582	559	527	527
query37	121	80	71	71
query38	992	839	792	792
query39	512	484	482	482
query39_1	451	465	443	443
query40	198	94	91	91
query41	70	70	67	67
query42	74	73	72	72
query43	238	237	207	207
query44	1020	551	554	551
query45	145	101	98	98
query46	784	852	525	525
query47	777	739	688	688
query48	310	295	233	233
query49	541	235	181	181
query50	781	262	194	194
query51	8032	8043	8070	8043
query52	66	67	57	57
query53	190	199	152	152
query54	248	171	186	171
query55	76	63	54	54
query56	197	171	159	159
query57	712	597	714	597
query58	203	164	159	159
query59	1198	1229	1076	1076
query60	233	185	177	177
query61	121	107	116	107
query62	378	204	169	169
query63	171	145	140	140
query64	2832	747	647	647
query65	1604	1634	1682	1634
query66	1814	269	249	249
query67	9776	9653	9700	9653
query68	3023	1237	687	687
query69	339	225	196	196
query70	657	621	609	609
query71	248	179	183	179
query72	2550	1739	1515	1515
query73	640	551	337	337
query74	1991	1227	1136	1136
query75	1164	1101	958	958
query76	2354	747	550	550
query77	260	261	212	212
query78	3873	3541	3208	3208
query79	2725	860	578	578
query80	1591	332	275	275
query81	517	164	130	130
query82	620	129	96	96
query83	288	210	187	187
query84	302	107	92	92
query85	868	359	301	301
query86	471	172	171	171
query87	1016	951	891	891
query88	2983	2124	2102	2102
query89	277	197	175	175
query90	2047	127	123	123
query91	133	124	98	98
query92	86	71	68	68
query93	2076	1132	734	734
query94	645	251	224	224
query95	538	318	224	224
query96	829	581	261	261
query97	1036	1070	1016	1016
query98	182	135	131	131
query99	419	337	303	303
Total cold run time: 179248 ms
Total hot run time: 81542 ms

[hello-stephen]

ClickBench: Total hot run time: 14.61 s

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

query1	0.00	0.00	0.01
query2	0.08	0.04	0.04
query3	0.25	0.11	0.11
query4	1.60	0.10	0.09
query5	0.17	0.16	0.15
query6	1.27	0.69	0.68
query7	0.03	0.01	0.00
query8	0.05	0.03	0.03
query9	0.28	0.21	0.21
query10	0.34	0.34	0.34
query11	0.16	0.12	0.12
query12	0.15	0.12	0.13
query13	0.29	0.32	0.31
query14	0.45	0.44	0.44
query15	0.36	0.34	0.35
query16	0.22	0.23	0.22
query17	0.72	0.65	0.66
query18	0.18	0.15	0.17
query19	1.11	1.15	1.17
query20	0.01	0.01	0.01
query21	15.46	0.15	0.11
query22	5.17	0.05	0.04
query23	16.18	0.25	0.10
query24	3.03	0.33	0.25
query25	0.11	0.04	0.03
query26	0.80	0.18	0.11
query27	0.04	0.04	0.03
query28	3.66	0.52	0.27
query29	12.47	3.20	2.54
query30	0.25	0.12	0.12
query31	2.75	0.36	0.16
query32	3.53	0.32	0.23
query33	1.36	1.46	1.50
query34	15.35	2.23	1.77
query35	1.76	1.73	1.73
query36	0.45	0.30	0.29
query37	0.06	0.04	0.03
query38	0.05	0.03	0.03
query39	0.04	0.02	0.02
query40	0.11	0.07	0.07
query41	0.07	0.02	0.02
query42	0.03	0.02	0.02
query43	0.03	0.03	0.02
Total cold run time: 90.48 s
Total hot run time: 14.61 s

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 64.06% (1745/2724) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[freemandealer]

/review

[github-actions]

Review completed in 2 rounds. All required full-coverage and risk-focused passes returned NO_NEW_VALUABLE_FINDINGS. After independent verification and deduplication against the existing review context, no new actionable inline finding remains; this is a summary-only review, and the review is complete rather than capped.

Critical checkpoint conclusions

• Goal and proof: The PR adds an opt-in COLOCATE MAPPING constraint and lets Nereids prove colocate joins from declared determinant-to-distribution-key mappings. The command, persistence, scan-property, aggregate/project propagation, and final join-proof paths implement that goal, with focused unit and regression coverage.
• Scope and clarity: Although the feature necessarily spans metadata, persistence, parser, planner properties, and tests, the changes stay within the FE-side constraint/planning contract and reuse the existing BE colocate-join execution path.
• Concurrency: Mapping ADD/DROP uses database-read -> table-write -> ConstraintManager locking, revalidates the concrete table while locked, submits the immutable journal payload with protected metadata, and performs await() after releasing metadata locks. The reviewed lock order is consistent and no deadlock or unjournaled publication path survived the lifecycle review.
• Lifecycle and static state: Mappings are owned by the concrete OlapTable.TableAttributes, so rename, recycle/recover, truncate, replace, copy, backup, and restore behavior follows physical table ownership. Restore and planning revalidate schema bindings. No new cross-TU/static-initialization or circular-lifetime issue applies to this Java-only change.
• Configuration: enable_colocate_mapping_constraint is a dynamic, plan-affecting experimental session variable and is disabled by default. Enabled and disabled planner behavior is covered; no process restart or FE-BE propagation is required.
• Compatibility: Image metadata uses an optional concrete field, and ADD/DROP reuse a backward-readable OP_MODIFY_TABLE_PROPERTIES envelope. Supported mixed/unknown-version operation fails explicitly through the exact-build gate; the documented downgrade and membership restrictions are consistent with older FEs ignoring the optional metadata. The challenged same-host heartbeat scenario requires an FE topology that cannot bootstrap/heartbeat with the cluster-global RPC/HTTP port contract, so it was dismissed rather than reported.
• Parallel paths: ADD, DROP, SHOW, replay, image load, backup/restore, schema change, HASH-to-RANDOM conversion, rename, replace, truncate, recycle/recover, selected rollups, and mapping-enabled scan planning were compared. No distinct omitted parallel path remained after deduplication.
• Special checks: Internal non-temporary OLAP ownership, Hash distribution, ordered target-key subsets, stable column identity/schema-version fallback, selected-index provenance, stable colocate group, table/index/partition identity, determinant order, target positions, and join equalities are all rechecked at the appropriate boundaries. Unsupported or redistributed property shapes fail closed.
• Test coverage: The added FE tests cover parser/command validation, constraint locking and binding, persistence/replay, restore rejection, schema and lifecycle behavior, scan provenance, property derivation/regulation/enforcement, aggregate/project propagation, join variants, composite/direct mappings, selected rollups, set operations, and the session gate. The full regression suite and expected output were reviewed, including ordered results and negative cases; no additional supported failure case survived the second pass.
• Test results: This review runner was explicitly restricted from builds and test execution, so no tests were rerun. The committed unit/regression code and expected result file were reviewed statically and are internally consistent with the changed behavior.
• Observability: User-visible failures name the incompatible frontend or mapping/table condition, and metadata mutation/replay paths have appropriate logging. No new critical runtime metric is required for this disabled-by-default planner optimization.
• Persistence and failover: Table attributes, edit-log submission, replay locking, backup copies, and restore validation cover the new metadata. New-FE replay/checkpoint preserves mappings, while supported mixed-version use is rejected before consumption; no distinct supported failover gap survived review.
• Data writes and atomicity: The feature does not alter DML, transactions, load, compaction, or BE data writes. The constraint is explicitly NOT ENFORCED, so Doris trusts the declared business invariant; metadata mutations remain atomic with their journal submission.
• FE-BE variables/protocol: No new FE-BE field, thrift payload, constant-folding path, or point-query variable is introduced. Execution continues through the existing colocate hash-join path.
• Performance: The optimization is disabled by default, does not insert an enforceable Exchange, and disables SQL-result caching only after a usable mapping proof is constructed. No new distinct CPU/memory or asymptotic issue survived; previously raised comparison-scale concerns were not duplicated.
• Other issues: The conservative schema-version invalidation for legacy columns is an explicit fail-closed contract, and the atomic-restore name-collision variant is covered by existing atomic-restore constraint-transition threads. No additional actionable issue remains.

[hello-stephen]

FE UT Coverage Report

Increment line coverage 78.40% (686/875) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[freemandealer]

/review

[github-actions]

Review status: complete after three review rounds; every candidate is accepted, duplicate-fenced, or dismissed with concrete evidence.

Requesting changes for three blocking correctness issues:

1. Hidden mapping locality can survive runtime boundaries that no longer preserve or truthfully report storage bucket-to-task placement, allowing an outer mapping-colocate join to build an expression-less bucket repair and miss matching rows.
2. Mapping DROP skips the atomic-restore ALTER fence, so a successful DROP can be silently reversed by the staged table swap.
3. Atomic restore can publish a table-local mapping whose name collides with an existing centralized constraint, leaving SHOW and mapping-enabled planning unusable.

Checkpoint conclusions:

• Goal and tests: the opt-in constraint model, stable schema binding, persistence, ordinary Project/Aggregate/join planning, compatibility fallback, and ordered result paths are broadly covered. Missing multi-task runtime-boundary cases and the two restore sequences correspond directly to the blocking findings.
• Scope and design: the patch is focused on mapping metadata, property derivation, join selection, lifecycle hooks, and tests. Mapping identity, determinant order/arity, target positions, selected-index provenance, and final two-child validation are otherwise conservative.
• Concurrency and locking: database-read -> table-write -> manager-write ordering, object revalidation, immutable journal payloads, and waiting outside metadata locks are sound. The concrete gap is the missing normal-state check on DROP during atomic restore.
• Lifecycle, persistence, and compatibility: legacy readers, replay, schema mismatch, and mixed/unknown FE state fall back conservatively. Atomic publication is the remaining unsafe boundary because it skips the DROP state fence and destination constraint namespace invariant.
• Parallel paths, configuration, and cache: the feature defaults off, participates in plan-result identity, and disables SQL result caching once consumed. Generate, Window/PartitionTopN, ordinary NLJ, and serial/force-passthrough broadcast are the verified runtime placement barriers; redistribution, set operations, Repeat/source-Aggregate, global ordering, CTE, and ordinary aggregate paths were cleared.
• Performance and observability: no new non-duplicate issue survived; existing candidate-scale and logging discussions were treated as hard duplicate fences.
• Verification: reviewed the authoritative 43-file bundle at head fc90803 against base 1197ae1 and deduplicated against the live review history. Per the review-only mandate, no local build or test was run. At submission time BE UT, Cloud UT, coverage, large-file, and review-status checks pass; Performance fails; Compile, FE UT, and automated code-review remain pending.

[nooneuse]

run buildall

[freemandealer]

/review

[github-actions]

Request changes: two P1 correctness blockers remain on the exact reviewed head. One rolling-upgrade sequence can durably lose a committed distribution mapping through a later old-FE checkpoint; one hidden-key COUNT(DISTINCT ...) plan can rebuild BUCKET placement with determinant/grouping hashes and produce a wrong-result colocate join. The review converged in Round 2 after a complete 44-file sweep, duplicate fencing against all existing threads, three independent normal passes, and a separate risk challenge.

Critical checkpoint conclusions:

• Goal and proof: the PR implements distribution-mapping DDL, persistence, optimizer proof propagation, and colocate planning, with substantial unit and regression coverage, but the two missing end-to-end cases below mean correctness is not yet established.
• Scope and focus: the 44 changed files are broad but cohesive around this feature; no unrelated source changes were identified. No additional user focus was provided.
• Concurrency: mapping ADD/DROP follows database-read -> table-write -> constraint-manager-write ordering, journals immutable payloads, and waits outside metadata locks. No new deadlock or lock-scope defect was found, but FE admission/election is outside the point-in-time compatibility check and creates the first blocker.
• Lifecycle and static/global state: table-owned mappings were traced through backup, restore, rename, replace, truncate, recycle, recover, image, and replay. Current-code ownership is coherent; no static-initialization, reference-cycle, or unreleased-lifecycle issue applies. The old-writer checkpoint lifecycle remains unsafe.
• Configuration: the new session flag is dynamic and included in result-affecting state; actual mapping use disables SQL result caching. Once enabled, default local-shuffle/distinct-streaming settings reach the second blocker.
• Compatibility: the new JSON envelope is parseable by old FEs but is not semantically round-trip-preserving if an old FE is admitted later and becomes leader/checkpointer. Rolling-upgrade safety is therefore incomplete.
• Parallel paths and conditions: schema changes, restore variants, selected-index binding, join orientation/types, projection/casts, set operations, Repeat, and known runtime barriers were traced. Existing barrier issues were not duplicated; the distinct-dedup Aggregate path is a separate uncovered condition. The compatibility and Aggregate guards have clear local intent, but their downstream invariants do not hold in the two reported sequences.
• Tests and results: changed unit/regression outputs were reviewed and are consistent with their queries. Negative syntax/schema, persistence, lifecycle, proof, and barrier coverage is extensive. Missing are ADD -> old-FE failover/checkpoint -> new-FE reload and a multi-bucket, multi-task asymmetric distinct-aggregate-vs-scan result test whose determinant hash differs from the storage-key hash. Per the review runner instructions, no builds or tests were executed.
• Error handling, memory safety, and nullability: this is FE Java metadata/planner work plus existing BE exchange consumption; no unchecked Status, C++ ownership/allocation, or BE nullable-column issue is introduced in the changed code. Analysis errors carry actionable constraint/version context.
• Observability: compatibility failure and mapping fallback paths have usable messages/rate-limited logging; no separate logging or metrics blocker was substantiated.
• Persistence and failover: current-code EditLog write/replay is symmetric and table-ID based, but old-FE semantic discard plus checkpoint cleanup violates failover durability as reported inline.
• Data writes and FE/BE variables: there is no BE storage-data mutation or new FE-to-BE configuration field. FE planner properties choose existing BE local-exchange modes; the second blocker is precisely a mismatch between the FE BUCKET claim and the expressions BE hashes.
• Performance: mapping/proof checks are bounded metadata work and the exact-version scan is on rare DDL/restore paths; no substantiated CPU, memory, or asymptotic regression was found.
• Other issues: the information_schema candidate was dismissed because TABLE_CONSTRAINTS is deliberately part of the MySQL key-metadata adapter, while SHOW CONSTRAINTS is Doris's broader registry. No unresolved candidate remains beyond the two inline P1s.

[hello-stephen]

FE UT Coverage Report

Increment line coverage 78.98% (710/899) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[freemandealer]

/review

[github-actions]

Reviewed exact head 1669edacec4b5af5c731d64eba7b28e111626927. Requesting changes for two correctness issues and one documentation contract mismatch: existing-table non-atomic Restore can retain an invalid destination mapping proof; CCR full sync can retain a stale proof after a source-side DROP; and the design documents overstate Atomic Restore support.

Checkpoint conclusions: the feature goal and default-off scope are coherent; DDL locking, replay durability, lifecycle handling, dynamic configuration, exact-FE admission, optimizer parallel paths, runtime barriers, observability, atomic publication, FE/BE interface boundaries, and mapping-index performance are otherwise sound or already covered by current duplicate-fenced threads. Persistence/failover and Restore/CCR lifecycle are not safe in the two cases called out inline. Comments and special-condition handling are consistent except for the Atomic Restore documentation. Test coverage is broad but misses the existing-target Restore and CCR DROP sequences described inline. No builds or tests were run, as required by the review prompt.

[hello-stephen]

FE UT Coverage Report

Increment line coverage 78.86% (746/946) 🎉
Increment coverage report
Complete coverage report

[nooneuse]

run buildall

[freemandealer]

/review

[github-actions]

Automated review result for exact head 645a1b81f81fd1a773f68829edae858d39761b6c: no new distinct blocking or actionable issue found.

Round 1 converged after three normal full-review passes and two separate risk-focused passes. Existing inline threads were treated as hard duplicate fences; the only plausible selected-rollup provenance concern was exactly covered by existing comment 3702605388, and the other follow-ups were dismissed with direct parser or restore-contract evidence.

Critical checkpoint conclusions:

• Goal and proof: the PR implements an opt-in, NOT ENFORCED table-local distribution-mapping proof for colocate joins. The scan, property, aggregate, join, translator, and fallback paths accomplish that goal, and the changed unit/regression artifacts cover direct and aggregate successes plus wrong-row barriers.
• Scope and clarity: the implementation stays focused on FE metadata, Nereids physical properties, parser/DDL, compatibility, and tests. I found no unnecessary FE-BE protocol or data-write expansion.
• Concurrency and locking: mapping ADD/DROP use database-read -> table-write -> constraint-manager locking, revalidate the concrete table and state while protected, submit the complete snapshot under the metadata locks, and wait for durability only after releasing them. Restore preflight occurs before publication; no distinct deadlock or unsafe failure window remained.
• Lifecycle: mappings follow the concrete table object across rename, recycle/recover, truncate, and replace/swap semantics. Backup, non-atomic restore, atomic-restore rejection, cancellation/replay, and CCR stripping were traced end to end; the live/backup mismatch, namespace collision, old-FE checkpoint, and CCR lifecycle concerns are already represented by existing review threads.
• Configuration: enable_colocate_mapping_constraint is an online experimental session variable, defaults off, participates in plan-result cache state, and promptly changes planner behavior.
• Compatibility: the persistent source of truth is a deterministic JSON snapshot in the existing generic TableProperty.properties envelope. Supporting FEs rebuild the derived map; older-FE-shaped round trips preserve the opaque key. Mixed/unknown FE versions make planning fall back and gate ADD/non-atomic mapped restore. No new wire symbol or storage-data format is introduced.
• Parallel and conditional paths: mapped base-column DROP/RENAME/MODIFY and HASH-to-RANDOM conversion are fenced; stale replayed bindings fail schema/type/unique-ID/layout compatibility and are ignored by planning. Selected rollups, projection/casts, set operations, Repeat/CTE, distinct/dedup, Generate, Window/PartitionTopN, nested-loop/broadcast joins, outer/mark joins, local shuffle, and plan recomputation were checked.
• Persistence and failover: ADD/DROP journal complete snapshots (including [] for the final DROP), replay rebuilds the derived state under the table lock, and allowed restore paths register the same validated object on leader and replay. No new unresolved EditLog or failover defect was substantiated beyond existing threads.
• Data writes and transactions: this change does not add a BE data-write or transaction path. The user assertion remains explicitly unenforced; correctness depends on the declared invariant, while planner consumption is gated by schema, version, stable colocate layout, and complete bucket-position proof.
• Tests and results: changed FE tests cover persistence, compatibility, restore/CCR, DDL lifecycle, property derivation, enforcer behavior, aggregates, and join selection. All 11 result queries have deterministic ordered expected-output sections, including non-coincidental multi-bucket wrong-row oracles and negative placement barriers. Per the review-runner instruction, I did not run builds or tests; this conclusion is based on code and committed test-artifact review.
• Observability and performance: fallback warnings are rate-limited and identify the table/reason; mapping planning is opt-in and candidate matching is indexed. I found no distinct material logging, CPU, memory, or asymptotic issue on this head.
• Other issues: none remained after the explicit 48-file final sweep and unresolved-candidate audit.

User focus: review_focus.txt supplied no additional focus, so the complete PR and all applicable Doris review checkpoints were reviewed.

Status: review complete on the exact bundled/live head; zero new inline comments.

[nooneuse]

run buildall

[hello-stephen]

FE UT Coverage Report

Increment line coverage 79.52% (761/957) 🎉
Increment coverage report
Complete coverage report