investigate(x/gamm/twap): Reconsider using fixed size unix time serialization to save space in db

[p0mvn]

Background

Example from one of the test cases:

"historical_pool_index|1|2009-11-10T23:00:00.000000001|"

We might save db space by choosing a shorter time serialization method.

There is no suggested design yet. The person taking on this issue should analyze the alternatives and summarize them here. If a new proposed design is accepted, it can be implemented.

Relevant Discussion: https://github.com/osmosis-labs/osmosis/pull/2199#discussion_r928045908_

Acceptance Criteria

• investigate alternatives related to time serialization
• summarize the findings in the comment to this issue

[p0mvn]

This is a nice to have but not a blocker

[pysel]

Hi, Jacob on Ruslan's laptop here-- this is fascinating!

I think that there are two ways that we can address this:

https://github.com/osmosis-labs/osmosis/blob/99f770f2f7969472928967c55f3e702a6fbdbd55/x/twap/types/keys.go#L49-L73

Are a number of functions returning byte slices that are just strings. So we could go content aware, and then use "whatever" serialization method, and all of the headers should be reduced to a single byte.

There is also a lazy method that could be used here--

https://github.com/klauspost/compress

has the s2 compression library, which we could use for every such case on osmosis.

snappy and s2 are very performant (cpu time for example) and also very effective (good compression). It might not be add good as a serialization library, but is possibly simpler and gets (nearly) the same effect.

wdyt?

[ValarDragon]

unfortunately I think we do need to close unfortunately. The TWAP code is code frozen aside from bug fixes, and this would require a state migration post-inclusion that seems not worth the marginal saving

Re: compression, we would need to ensure it preserves sort and length ordering guarantees. Which seems not worth it, and the tradeoff of fixed sized byte encoding seems totally ok