Github user kl0u commented on the issue: https://github.com/apache/flink/pull/4172 @dianfu and I also include @wuchong on this as these two are related. The way I see it is that by not serializing the condition and the states, you are trying to gain some speed, especially when using RocksDB where you serialize/deserialize on every element, right? My suggestion is to not do these optimizations yet. At first, because this seems like a pre-mature optimization to me as we are not sure yet about the interplay between all the features we are planning to put in `CEP`, and we know that if we allow users to add `Patterns` at runtime, then we will need 1) to store both States and Conditions and 2) match the States and Conditions of a given NFA with its SharredBuffer. In other words, we will need a unique Id for each NFA, that will match the restored sharedBuffer (which is still serialized and deserialized as before) with the States (`metastates` in this PR) and Conditions (`ConditionRegistry` in https://github.com/apache/flink/pull/4145) of the NFA. So I propose to implement this https://issues.apache.org/jira/browse/FLINK-7008 and https://issues.apache.org/jira/browse/FLINK-6938 right away so that we can proceed with the SQL integration, and think a more general solution for checkpointing separately the static state of the NFA (state and conditions) from the dynamic one (sharedbuffer), which will lead to runtime gains.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---