Open DmitriiAn opened 2 months ago
Yeah, I guess it's not possible to configure normally now, because the compress_chunk_time_interval
is always Interval, and for the integer columns it is converted to microseconds, but they are using the nanosecond units, so this is where the mismatch comes from. I guess that to fix it, we could treat it same as we do chunk_time_interval
which is a bigint.
For the time being, I have a dumb workaround:
ALTER TABLE public.device_metrics SET (timescaledb.compress,
timescaledb.compress_chunk_time_interval = '7000 days'
);
Just increase the interval 1000x, so that when it's converted to microseconds, you get the desired value in nanoseconds.
What type of bug is this?
Configuration, Incorrect result
What subsystems and features are affected?
Compression
What happened?
if timestamp in a hypertable is a BIGINT, there is no way to use compress_chunk_time_interval https://docs.timescale.com/api/latest/compression/alter_table_compression/
I would expect to use
timescaledb.compress_chunk_time_interval = BIGINT
, but it does not work.TimescaleDB version affected
2.14.2
PostgreSQL version used
15.6
What operating system did you use?
-
What installation method did you use?
Not applicable
What platform did you run on?
Timescale Cloud
Relevant log output and stack trace
No response
How can we reproduce the bug?