new metric in postgres_driver to estimate payload stats

[Ivansete-status]

Original PR: #3544

The original PR got abruptly closed after a deep cleanup and refactor applied by this on 2025-09-30

Issue

• Maintenance Y2025H2 #3483

[github-actions]

This PR may contain changes to database schema of one of the drivers.

If you are introducing any changes to the schema, make sure the upgrade from the latest release to this change passes without any errors/issues.

Please make sure the label release-notes is added to make sure upgrade instructions properly highlight this change.

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3596

Built from f3d4ca9

[NagyZoltanPeter]

Need some more clarification about this.

[NagyZoltanPeter]

Sorry, I don't get the mean of this gauge. Is it about to show the last message payload size, or should it somehow sum up?
How should itt help in maintaining DB space?

[Ivansete-status]

Sure!
The original idea is to track the average message size stored in the databases over time. This serves as a small step toward better understanding overall database usage.

[NagyZoltanPeter]

It is only set to the last message size always. Was it the aim?

[Ivansete-status]

Unless I'm missing something, it writes all messages' sizes

[NagyZoltanPeter]

Yes, it writes all, just does not sum them up. That made me think the approach. But than as @fcecin gave insight I'm ok with it.

[fcecin]

This is a "best-effort estimate" metric kept in RAM for free. The documentation provided is general and allows it to implement the estimate in different ways (sliding window/running average) in the future. There's no promise in the gauge description string that this has to be a running average of some sort, which is good. It's good to start with the simplest, N=1. I'm actually wondering how far we can go with just this.

[NagyZoltanPeter]

Thank for the explanation! It is good to go!

[fcecin]

Another thing we can do (later, or roll in this PR) is add two other gauges: total message count and total message size, then use inc() (instead of set()) on these two gauges when a message arrives (so add +1 on message count and +msg-size-bytes on the bytes counter). This way we can push whether to use a sliding window or whether to just use the simple average since start of measurement to whatever code is sitting on top of this -- the upper layer ("grafana"??) can poll the two gauges and decide to do some sliding metric, which I guess is how this is supposed work? (haven't done much metrics stuff...)

For example, the gauges at T=1: count=0 bytes=0, T=2: count=1 bytes=1000, T=3: count=2 bytes 1020. With no sliding window the simple average is 510 (1020 / 2). with a sliding-window-size=1 that excludes T=2 and only considers T=3 (dumb example, but works), the average is now 20 (20 / 1). Whoever is polling the gauges (at whatever rates) decides what to do, instead of us ever solving that problem here.

[Ivansete-status]

Thanks for the comments!
@fcecin - I think we can revisit that in the future. The gauge metric is used in values that can either increase or decrease. Grafana can extract the stats automatically for us