David Moravek

I'm actually starting to doubt whether the feature is even worth it for partitioned state. The compressed representation might actually end up being bigger than uncompressed one. To make it...

@flinkbot run azure

> Yeah exactly. I wonder - is it hard to simply not do compression for partitioned state (but keep doing it for broadcast state)? It requires changing the wire format.

> I have an inelegant solution: @fredia After https://github.com/apache/flink/pull/24079/commits/6bb32b114b76515757e602612dcf33668d031fef the sorting is no longer important, because that allows us to seek wherever we want. It's still a nice optimization to...

> So that the order of our offset is no longer important, and compatibility does not need to be specially considered. I don't think that needs to be considered at...

> it also solves the the compressed representation might actually end up being bigger than uncompressed one problem. Not completely, since we're doing per-value compression for list states, (I'm not...

There might actually be something more fancy going on, need to read up on it at some point :D https://en.wikipedia.org/wiki/Snappy_(compression)

Can you please link the commits with a corresponding JIRA issue?

```bash $ git grep PROXIMA-220 flink/core/src/main/java/cz/o2/proxima/flink/core/BatchLogSourceFunction.java: * @see PROXIMA-220 ```