[
https://issues.apache.org/jira/browse/FLINK-26490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flink Jira Bot updated FLINK-26490:
-----------------------------------
Labels: auto-deprioritized-major auto-deprioritized-minor
pull-request-available (was: auto-deprioritized-major pull-request-available
stale-minor)
Priority: Not a Priority (was: Minor)
This issue was labeled "stale-minor" 7 days ago and has not received any
updates so it is being deprioritized. If this ticket is actually Minor, please
raise the priority and ask a committer to assign you the issue or revive the
public discussion.
> 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)
