Apply create_hypertable(..., migrate_data=>true) to turn this table into a hypertable.
Observation/Bug:
The index which gets created on the time column by timescale is broken and unusable for the query planner. Therefore, the query planner always uses seq scans instead of index scans.
This behaviour only occurs when we migrate data, whereas creating the hypertable first and then inserting data doesn't cause any indexing issues.
Reindexing fails:
We tried to reindex and received the following results:
Postgres scans all partitions, instead of checking the partition with the youngest timestamp.
Fix/Workaround:
We fixed the issue by manually creating a new index on the hypertable.
-- Query
create index time_index on test_data_timescale_index_migration_bug (time desc);
Then we get the expected index scans in the query plan:
-- Output
-> Index Scan using _hyper_29684_894837_chunk_time_index on _hyper_29684_894837_chunk (cost=0.12..2.34 rows=1 width=12) (actual time=0.020..0.020 rows=1 loops=1)
-> Index Scan using _hyper_29684_894836_chunk_time_index on _hyper_29684_894836_chunk (cost=0.12..2.34 rows=1 width=12) (never executed)
...
drop table if exists test_data_timescale_index_migration_bug;
create table test_data_timescale_index_migration_bug as (select time, random() as value from generate_series(
'2021-01-01',
'2022-01-01', INTERVAL '7 days'
) as time);
select create_hypertable('test_data_timescale_index_migration_bug', by_range('time'), migrate_data=>true);
explain analyze
select * from test_data_timescale_index_migration_bug
order by time desc
limit 1;
What type of bug is this?
Performance issue
What subsystems and features are affected?
Query planner
What happened?
Scenario:
Observation/Bug: The index which gets created on the time column by timescale is broken and unusable for the query planner. Therefore, the query planner always uses seq scans instead of index scans.
This behaviour only occurs when we migrate data, whereas creating the hypertable first and then inserting data doesn't cause any indexing issues.
Reindexing fails: We tried to reindex and received the following results:
We concluded, after checking pg_indexes by executing
that the index on the hypertable is correctly registered, but must be broken in some way.
Query Planner Results
explain analyze confirmed that the timescale index does not work.
Query:
Query plan using timescales default index:
Postgres scans all partitions, instead of checking the partition with the youngest timestamp.
Fix/Workaround: We fixed the issue by manually creating a new index on the hypertable.
Then we get the expected index scans in the query plan:
Now we see the expected behaviour.
Credits: @probstal, @theokli, @BastianHentschel, @alx-net
TimescaleDB version affected
2.14.2
PostgreSQL version used
16.2
What operating system did you use?
Ubuntu 21.04 x86_64
What installation method did you use?
Deb/Apt
What platform did you run on?
On prem/Self-hosted
Relevant log output and stack trace
How can we reproduce the bug?