timescaledb
timescaledb copied to clipboard
timescale
Allow dropping FK on compressed tables
What type of bug is this?
Performance issue
What subsystems and features are affected?
Compression
What happened?
https://timescaledb.slack.com/archives/C4GT3N90X/p1689184154731459 In short customer wants to drop FK constraints on hypertables, when compression is enabled, however he could not do it.
TimescaleDB version affected
2.12.0
PostgreSQL version used
15.2
What operating system did you use?
Mac OSX
What installation method did you use?
Source
What platform did you run on?
On prem/Self-hosted
Relevant log output and stack trace
No response
How can we reproduce the bug?
CREATE TABLE meta (device_id INT PRIMARY KEY);
CREATE TABLE hyper(
time INT NOT NULL,
device_id INT REFERENCES meta(device_id) ON DELETE CASCADE ON UPDATE CASCADE,
val INT);
SELECT * FROM create_hypertable('hyper', 'time', chunk_time_interval => 10);
ALTER TABLE hyper SET (
timescaledb.compress,
timescaledb.compress_orderby = 'time',
timescaledb.compress_segmentby = 'device_id');
INSERT INTO meta VALUES (1), (2), (3), (4), (5);
INSERT INTO hyper VALUES (1, 1, 1), (2, 2, 1), (3, 3, 1), (10, 3, 2), (11, 4, 2), (11, 5, 2);
-- compress chunks
select compress_chunk(c) from show_chunks('hyper') c;
-- drop constraint
alter table hyper drop constraint hyper_device_id_fkey;
Thank you @sb230132 for adding this issue.
This is more of a blocker / functionality we do not offer than a performance issue. This is the first time we got a request for this functionality, but it is a valid and reasonable one. The severity and priority should be below the current priorities for Q3, but if we can address this in a timely fashion (as part of revisiting our locking on compressed hypertables or as a stand alone issue), it would remove one more blocker for our users.
/cc @horzsolt
