space partition incorrectly excluded for DML based on cross-type comparison
Author: akuzmCreated Sep 16, 2026Updated Sep 16, 2026
Labelsbugplanner
-- DELETE on a hash dimension misses the row when the equality literal
-- has a different type than the partition column (date column, timestamp
-- literal). With timescaledb.enable_optimizations = off the same DELETE
-- removes the row.
CREATE TABLE ferry_sailings (
departs_at timestamptz NOT NULL,
route_added_on date NOT NULL
);
SELECT create_hypertable('ferry_sailings', 'departs_at');
SELECT add_dimension('ferry_sailings', 'route_added_on', number_partitions => 2);
INSERT INTO ferry_sailings VALUES ('2024-01-15 08:00:00+00', '2024-01-15');
-- baseline: optimizations off, the row is found
BEGIN;
SET LOCAL timescaledb.enable_optimizations = off;
DELETE FROM ferry_sailings WHERE route_added_on = '2024-01-15'::timestamp; -- DELETE 1
ROLLBACK;
-- default settings: the same statement misses the row
BEGIN;
DELETE FROM ferry_sailings WHERE route_added_on = '2024-01-15'::timestamp; -- DELETE 0, expected DELETE 1
ROLLBACK;Looks like we're using wrong hash function. The problem occurs when we transform the clause into the form that can be handled by Postgres constraint exclusion. This is a leftover of the old code that didn't use the normal hypertable expansion for DML. In hypertable expansion, a similar problem was fixed here: https://github.com/timescale/timescaledb/pull/9344
This might become relevant for runtime chunk exclusion in ChunkAppend based on a parameterized clause that filters on space dimension. We don't implement this at the moment.
Other than that potential use, this code looks like it could be just deleted.
Source: timescale/timescaledb