Separate DB weights for top and child keys

[ggwpez]

paritytech/substrate#12021 allows to also benchmark child storage keys.
We can now then think about how to generate custom weights for both and combine them, instead of directly combining them.
One use-case is that some chains may have much more child than top keys or vice-versa.

There are multiple approaches:

• Extend RuntimeDbWeight struct (Will collide with WeightsV2)
• Modify the template to contain three RuntimeDbWeight (top, child and combined)
• Combine them in the CLI with a ratio option, like --child-key-weight-ratio PERCENT.

[bkchr]

Why would you need to separate them? Is the db weight calculated based on the maximum depth of the main trie?

[ggwpez]

This would only help in case that the developer knows that child keys will be read with higher or lower probability than top keys.
The dev could then set --child-key-weight-ratio to 80% or whatever, to indicate that a random read/write has a 80% chance of being a child key.

So it's not strictly needed but more of an optimization for power users.

[bkchr]

Yeah I got this. I just don't know how this influences the weight calculation.

[ggwpez]

It does not influence the formula with which it is calculated, but how granular the output is.
Currently we throw all collected time samples into one bucket and then average.
The new version would have one top-, and one child-bucket to collect the results.
The developer could then compose the results from these two weights into a final weight.
I am not sure how this would best be exposed to the devs, hence this issue.