[WIP] Redesigning the hypertable for compression and similar features

[noctarius]

This PR is a work in progress to test and work on a redesign of the timescale part of the implementation. The main focus is to minimize disk space consumption, increase the compressibility of the table and apply some general best practices.

This PR may eventually resolve #25

[freol35241]

@noctarius

I can see that you are putting a lof of effort in this and I am grateful for that. But just to be clear, removing the id column is a definitive yes from my side whereas the separate table/ltree approach to the attributes is interesting but merging of it is highly dependant on the complexity introduced to the codebase.

[noctarius]

Which is fair. No worries on that. The complexity is fairly low, as you can see from the code changes. Happy to fork it out if you don't want to deal with it. I'm basically doing it for myself. Even though I hate Python 😅

[antoonhuiskens]

nice work sofar! I'm spending quite some time refining my timescaledb setup. One of the nice things you can do is rollup of chunks into larger compressed chunks, improving compression even more. In order to gracefully work, there's two things to consider:

• compression policy to use
  • compress_orderby = 'time ASC'
  • compress_segmentby = 'entity_id'
• the compress_chunk_time_interval needs to be an integer multiple of the chunk_interval. (i.e. 7 day chunks to 28 days compressed would work, but 7 day chunks to 30 day compressed wouldn't.
• maybe also consider the version of timescaledb... since only since 2.11 there's no constraints on updating data in compressed chunks.

segment_by is documented here: https://docs.timescale.com/use-timescale/latest/compression/compression-design/

order_by time ASC is documented here:
https://docs.timescale.com/use-timescale/latest/compression/manual-compression/#roll-up-uncompressed-chunks-when-compressing