[Enhancement] Pre-split base and rollup for INSERT-from-table into a range table#76392
[Enhancement] Pre-split base and rollup for INSERT-from-table into a range table#76392xiangguangyxg wants to merge 1 commit into
Conversation
|
@codex review |
|
Codex Review: Didn't find any major issues. Delightful! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Shared-data e2e validation (TSP build 2611, 1 FE + 3 CN, ubuntu)Range table
Both the base index and the divergent rollup pre-split from the same sample, with per-index boundaries computed from the correctly-remapped source columns; every non-eligible source skips without a fallback. FE unit suite (presplit + broker) 636/0/0, checkstyle clean. |
3c8caaf to
c1a6bbe
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
bc7cb88 to
b89c10a
Compare
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 47 / 47 (100.00%) file detail
|
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
b89c10a to
cd4619c
Compare
|
@codex review |
|
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
…range table Sample-Based Tablet Pre-Split previously skipped INSERT ... SELECT ... FROM a single OLAP table when the range-distribution target carried a rollup, because the sampler could only project the base sort key and only by target column name. This makes INSERT-from-table split every visible index (base plus each rollup): - InsertFromTableScanContext carries the full target->source column-name map instead of a base-only source-column list, and the data-tier executor maps whatever sort key it is handed (request.getSortKey() for the base; each rollup spec's sort key for the secondary projection) through that map. - The shared secondary-index projection becomes an overridable executor seam whose default projects by target column name (FILES / Broker byte-identical); INSERT-from-table overrides it to remap to source names. - TablePreSplitSource builds one secondary index spec per visible rollup. - The two guards that skipped multi-index INSERT-from-table are removed. Single-index INSERT-from-table is byte-identical (the base sort key maps to the same source names). FILES / Broker and the ALTER-side pre-split path are untouched. Any unmapped sort-key column fails the sample so the load proceeds without pre-split. Data tier only (an OLAP source has no Parquet/ORC footer). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: xiangguangyxg <xiangguangyxg@gmail.com>
cd4619c to
f9476c2
Compare



Why I'm doing:
Sample-Based Tablet Pre-Split previously skipped
INSERT ... SELECT ... FROM <single OLAP table>whenever the range-distribution target carried a rollup, so on such a load neither the base index nor the rollup got pre-split (they stayed at one tablet and relied on post-load auto-merge/compaction). PR #76233 shipped multi-index pre-split for FILES/Broker loads but documented INSERT-from-table + rollup as a descope, because the sampler could only project the base sort key and only by target column name, whereas INSERT-from-table must project by the source column name via the target->source column remap.What I'm doing:
Make INSERT-from-table split every visible index (base plus each rollup):
InsertFromTableScanContextnow carries the full target->source column-name map instead of a base-only source-column list. The data-tier executor maps whatever sort key it is handed through that map:request.getSortKey()for the base (in the multi-partition single-request flow, and per-index in the single-partition flow), and each rollup spec's sort key for the secondary projection.AbstractSqlSampleSubqueryExecutor.secondaryIndexProjectionIdents). The default projects by target column name, so FILES/Broker generate byte-identical SQL; INSERT-from-table overrides it to remap to source names.TablePreSplitSourcenow builds one secondary index spec per visible rollup.Safety: single-index (no-rollup) INSERT-from-table is byte-identical (the base sort key maps to the same source names). FILES/Broker and the ALTER-side pre-split path are untouched. Any unmapped sort-key column fails the sample so the load simply proceeds without pre-split (a base-only or no split is data-safe, since the BE routes each row by its true value). Data tier only -- an OLAP source has no Parquet/ORC footer, so the meta tier is already bypassed for this load kind.
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: