[
https://issues.apache.org/jira/browse/FLINK-23031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aitozi updated FLINK-23031:
---------------------------
Description:
Currently, Flink support early trigger for Window Operator, But it will trigger
periodically after the first element in. This come up with two drawback
1. It will bring overhead to the heap memory, especially for the job with large
scale number of group by key
2. The same result will be compute repeatedly , but not deliver by Window
Operator. It's somehow meaningless work.
We can simply avoid to register next timer in {{onProcessingTime}} phase to
optimize the performance. Due to the Window Operator already eliminate the same
output, So this change will not
cause compatible problem
was:
Currently, Flink support early trigger for Window Operator, But it will trigger
periodically after the first element in. This come up with two drawback
1. It will bring overhead to the heap memory, especially for the job with large
scale number of group by key
2. The same result will be compute repeatedly , but not deliver by Window
Operator. It's somehow meaningless work.
We can simply avoid to register next timer in {{onProcessingTime}} phase to
optimize the performance. Due to the Window Operator already
> Support to emit window result with periodic or non_periodic
> -----------------------------------------------------------
>
> Key: FLINK-23031
> URL: https://issues.apache.org/jira/browse/FLINK-23031
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / Planner
> Reporter: Aitozi
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Currently, Flink support early trigger for Window Operator, But it will
> trigger periodically after the first element in. This come up with two
> drawback
> 1. It will bring overhead to the heap memory, especially for the job with
> large scale number of group by key
> 2. The same result will be compute repeatedly , but not deliver by Window
> Operator. It's somehow meaningless work.
> We can simply avoid to register next timer in {{onProcessingTime}} phase to
> optimize the performance. Due to the Window Operator already eliminate the
> same output, So this change will not
> cause compatible problem
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
