Sven Klemm

Hmm I cannot reproduce with the script you provided. I'm getting no decompression for that delete. ``` sven@i7110[378424]=# EXPLAIN analyze delete from observations where report_id = 49051 and generated_at =...

This works in recent versions.

Does it work if you dont skip internmediate version?

135 commits in a single PR is quite big. I think it would speed up reviewing if the PR was split up into smaller parts so it could be merged...

Currently this PR segfaults when non-btree/non-hash indexes are present. We should probably error out in those cases instead of segfaulting.

We toned this down a bit in recent versions and should be less spammy now

gapfilling is not designed for interpolating NULL values but for actual missing data. If you have NULL values interpolate will not interpolate those. There is an option to treat NULLs...

Maybe we should enforce source file name to be unique in general, would improve convenience in some situations.

2.11.0 is very old version, can you reproduce this on the most recent version?

Are you following the procedure outlined in https://docs.timescale.com/timescaledb/latest/how-to-guides/backup-and-restore/pg-dump-and-restore/#restore-your-entire-database-from-backup Specifically are you using timescaledb_pre_restore() and timescaledb_post_restore()?