[
https://issues.apache.org/jira/browse/FLINK-26490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785394#comment-17785394
]
Yuan Mei commented on FLINK-26490:
----------------------------------
Sorry to respond late. Just saw this ticket recently.
I think we should be cautious about loosing checks for MaxParallelism.
# In general, MaxParallelism is not expected to be changed (at least changed
often) after starting a job. A more strict check on "MaxParallelism" is not too
big a problem.
# The other thing is should OPstate be completely not affected by
"MaxParallelism". I know it is not affected today, but if we change the
contract between "MaxParallelism" and "State", we need to think of all these
corner cases if we make any changes later.
I am concerned about making such changes.
> Adjust the MaxParallelism or remove the MaxParallelism check when unnecessary.
> ------------------------------------------------------------------------------
>
> Key: FLINK-26490
> URL: https://issues.apache.org/jira/browse/FLINK-26490
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / State Backends
> Reporter: chenfengLiu
> Priority: Not a Priority
> Labels: auto-deprioritized-major, auto-deprioritized-minor,
> pull-request-available
>
> Since Flink introduce key group and MaxParallelism, Flink can rescale with
> less cost.
> But when we want to update the job parallelism bigger than the
> MaxParallelism, it 's impossible cause there are so many MaxParallelism check
> that require new parallelism should not bigger than MaxParallelism.
> Actually, when an operator which don't contain keyed state, there should be
> no problem when update the parallelism bigger than the MaxParallelism,, cause
> only keyed state need MaxParallelism and key group.
> So should we remove this check or auto adjust the MaxParallelism when we
> restore an operator state that don't contain keyed state?
> It can make job restore from checkpoint easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
