prefer-timescale-drop-chunks

What It Detects

Time-ranged DELETE on a hypertable. drop_chunks() removes the same data far more cheaply.

Why It's Dangerous

Deleting old data row by row is the most expensive way to do the job: a WAL record per row, a dead tuple per row for vacuum to clean up later, and bloat that stays until the vacuum finishes. On a hypertable that work is also unnecessary — chunks are already partitioned on the time column, so the rows in a retention window are whole chunks, and drop_chunks() drops them as tables. No per-row work, and the space comes back immediately rather than after a vacuum.

Bad Example

DELETE FROM metrics WHERE time < now() - interval '30 days';

Good Example

SELECT drop_chunks('metrics', older_than => INTERVAL '30 days');

-- drop_chunks only removes chunks whose entire range falls outside the
-- bound, so rows in a partially-covered chunk survive.

Configuration

Disable this rule:

# .migrationpilotrc.yml
rules:
  MP106: false

Or change its severity:

# .migrationpilotrc.yml
rules:
  MP106:
    severity: warning