Skip to content

Docs: Add doc for flink table maintenance ConvertEqualityDeletes#17113

Open
Guosmilesmile wants to merge 2 commits into
apache:mainfrom
Guosmilesmile:add_doc_convert_equality
Open

Docs: Add doc for flink table maintenance ConvertEqualityDeletes#17113
Guosmilesmile wants to merge 2 commits into
apache:mainfrom
Guosmilesmile:add_doc_convert_equality

Conversation

@Guosmilesmile

Copy link
Copy Markdown
Contributor

No description provided.

@Guosmilesmile Guosmilesmile changed the title Add doc convert equality Docs:Add doc for flink table maintenance ConvertEqualityDeletes Jul 6, 2026
@github-actions github-actions Bot added the docs label Jul 6, 2026
@Guosmilesmile Guosmilesmile changed the title Docs:Add doc for flink table maintenance ConvertEqualityDeletes Docs: Add doc for flink table maintenance ConvertEqualityDeletes Jul 6, 2026
@Guosmilesmile Guosmilesmile reopened this Jul 6, 2026
@Guosmilesmile Guosmilesmile changed the title Docs: Add doc for flink table maintenance ConvertEqualityDeletes Docs: Add doc for flink table maintenance ConvertEqualityDeletes Jul 6, 2026

**State and restart**

- The PK-index worker keeps a keyed row-position index of the target branch in Flink state. Its size scales with the number of live rows in the table for the configured equality columns; size Flink state backend, checkpoint storage, and TaskManager memory accordingly.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[for my understanding] is this done in an incremental manner from the last check-pointed state ?


**Concurrent commits on the target branch**

- External commits to the target branch (e.g. compaction, direct writes) are detected by `RowDelta.validateFromSnapshot`. A conflicting cycle fails at commit; the next trigger reindexes the worker's PK index from the new target head and retries.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we wanna put a recommendation to avoid concurrent writes to the tables ? i understand we can rebase / re-index and then retry but i wonder how practical it is for the next attempt to succeed if there is another writer writing to the table continuously

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants