Alexander Kuzmenkov

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...

Do you have any old-format continuous aggregates? You can check with `select * from _timescaledb_catalog.continuous_agg where not finalized;`. I found one similar report: https://github.com/timescale/timescaledb/issues/5905

What exactly is broken? I reproduced it but I have no idea what's going on... Theoretically, the `make_restrictinfo` should take care of creating the proper `orclause` as well.

> Potentially yes. Ideally we can reenable this in followup PR after we fix OR processing. Let's go with the thing we discussed on Slack -- avoiding nested AND boolexprs...

Thanks for the script, it reproduces for me. The error is related to the NULL value of the `end_offset`, so probably as a workaround you can set it to something...

> Any reason not to merge this? Seems like it would improve things. There's still some flakiness that I'm investigating in https://github.com/timescale/timescaledb/pull/6893 So this means this PR is probably going...

Sorry about that, I think it's a bug in implementation of vectorized filters in TimescaleDB. I didn't realize Postgres used a different convention for NaNs. Nice workaround, there's also a...

> In my largest hypertable all the chunks seem to have rolled themselves into one huge chunk Let's figure this out first. This is not something that should happen by...

> ``` > ?column? | min | max > -------------------------------------------+----------------------------+---------------------------- > _timescaledb_internal._hyper_29_338_chunk | 1970-01-20 19:56:39.491+12 | 1970-01-21 06:23:32.394+12 > (1 row) > ``` So this means that the timestamps of...

> @akuzm was looking at this test flakiness, not sure if it addresses this exact problem #6550 Yeah that's the one that went up to fixes in Postgres :) Trying...