Thanks for the KIP Evan.
MJS1: Why is the metric added at DEBUG level? The corresponding RocksDB
metric is added at INFO level. The KIP says:
The addition of this metric will have no effect on existing users. The performance impact of adding this metric is non-trivial, thus we only record it at the DEBUG level.
Why is it expensive? Not clear to me atm. And why would it be cheaper
for the RocksDB case?
About Lucas question: Not sure if we would need to do anything about it?
Given that we have specific RocksDB metrics, which are not available for
in-memory stores, why should we not have specific in-memory store
metrics? RocksDB metrics are also not containing "rocksdb" in their names?
As long as it's properly document as "in-memory metric" (and the
description already mentions it explicitly) it might just be fine?
MJS2: The KIP says, we would implement this only for
`MeteredKeyValueStore`. Why not also add it to the other store types
like windowed and others?
-Matthias
On 12/12/25 4:14 PM, Evan Zhou via dev wrote:
Hi Lucas,
Thanks for the feedback.
My original intention was to use "estimate" in the metric name as the
differentiator, but I agree that this is not very clear. How does changing
the metric name to "in-memory-state-num-keys" sound?
Thanks,
Evan
On Thu, Dec 11, 2025 at 1:21 AM Lucas Brutschy via dev <[email protected]>
wrote:
Hi Evan,
thanks for the KIP!
If this is specific to in-memory stores, I wonder if we should add
this to the metric name? People could become confused that rocksDB
state is not showing up.
Cheers,
Lucas
On Thu, Dec 11, 2025 at 1:40 AM Evan Zhou via dev <[email protected]>
wrote:
Hi all,
I'd like to start the discussion for KIP-1250, which adds a new metric to
track the size of in-memory state stores. Today, a similar metric exists
in
Kafka, but only for RocksDB, and this KIP intends to close that gap.
https://cwiki.apache.org/confluence/x/noTMFw
Thanks,
Evan
