[ 
https://issues.apache.org/jira/browse/FLINK-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727251#comment-16727251
 ] 

Hequn Cheng commented on FLINK-11188:
-------------------------------------

[~fhueske] Hi, thanks for your reply. I think you are right. Rows-bounded over 
should support retention time. The state will not be cleaned up automatically. 
The accumulators in rows-bounded over will be kept forever similar to the 
unbounded group by.

I find that range-bounded over can't automatically clean up their state either. 
Under the current implementation, accumulators are only cleaned by retention 
time strategy. We could:
 - add automatic cleanup logic for them.
 - stick to retention time strategy.

I personally prefer the first option.
- The dedicate cleanup logic can both support rowtime and proctime.
- It can clean up the state automatically, i.e., users don't need to know it.
- It only removes expired data according to the range of over window which will 
not result in incomplete/invalid results

What do you think?

> Bounded over should not enable state retention time 
> ----------------------------------------------------
>
>                 Key: FLINK-11188
>                 URL: https://issues.apache.org/jira/browse/FLINK-11188
>             Project: Flink
>          Issue Type: Bug
>          Components: Table API & SQL
>            Reporter: Hequn Cheng
>            Assignee: Hequn Cheng
>            Priority: Major
>
> As discussed in FLINK-11172, time-based operations (GROUP BY windows, OVER 
> windows, time-windowed join, etc.) are inherently bound by time and 
> automatically clean up their state. We should not add state cleanup or TTL 
> for these operators.
> If I understand correctly, we should not add the retention logic for 
> rows-bounded operations either. I think we should disable state retention 
> logic for:
>  - ProcTimeBoundedRangeOver
>  - ProcTimeBoundedRowsOver
>  - RowTimeBoundedRangeOver
>  - RowTimeBoundedRowsOver
> Any suggestions are appreciated!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to