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

Kostas Kloudas commented on FLINK-9507:
---------------------------------------

Hi [~aitozi]!

This is a very nice idea and something that we were also considering for future 
versions of the CEP library. The reason why this is not yet implemented is 
because in CEP, contrary to Flink's windowing mechanism, an element can belong 
to multiple partial matches and it can also be eligible for future partial 
matches.

This makes things a little bit more complicated, so I would recommend to wait 
till the end of the week till this PR 
[https://github.com/apache/flink/pull/6059|https://github.com/apache/flink/pull/6059/commits]
 goes in (because it refactors the shared buffer) and then submit a design 
document before starting to code. 

I would be more than happy to help with the design and the reviewing.

> Introduce ReduceFunction to CEP to minor the cost for IterativeCondition
> ------------------------------------------------------------------------
>
>                 Key: FLINK-9507
>                 URL: https://issues.apache.org/jira/browse/FLINK-9507
>             Project: Flink
>          Issue Type: Improvement
>          Components: CEP
>    Affects Versions: 1.5.0
>            Reporter: aitozi
>            Assignee: aitozi
>            Priority: Major
>             Fix For: 1.6.0
>
>
> When we use the cep to describe a condition about the events that has been 
> matched, we have to call the method  "getEventsForPattern" to extract the 
> partly matched elements from the sharedBuffer in RocksDB, which is very cost, 
> I think we can introduce a ReduceFunction on the pattern desc to allow us to 
> aggregate the value  in advance.  Is this practical ? What's your guys 
> opinion? [~kkl0u] [~dawidwys]



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

Reply via email to