[
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 brings 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 eliminate the same
output, So this change will not
cause compatible problem
> 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 brings 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)
