ha executor

migrations/20250101000009_timescaledb_history.sql

@@ -143,52 +143,8 @@ SELECT create_hypertable('event', 'created',
 
 COMMENT ON TABLE event IS 'Events are instances of triggers firing (TimescaleDB hypertable partitioned on created)';
 
--- ============================================================================
--- CONVERT ENFORCEMENT TABLE TO HYPERTABLE
--- ============================================================================
--- Enforcements are created and then updated exactly once (status changes from
--- `created` to `processed` or `disabled` within ~1 second). This single update
--- happens well before the 7-day compression window, so UPDATE on uncompressed
--- chunks works without issues.
---
--- No FK constraints reference enforcement(id) — execution.enforcement was
--- created as a plain BIGINT in migration 000005.
--- ----------------------------------------------------------------------------
-
-ALTER TABLE enforcement DROP CONSTRAINT enforcement_pkey;
-ALTER TABLE enforcement ADD PRIMARY KEY (id, created);
-
-SELECT create_hypertable('enforcement', 'created',
-    chunk_time_interval => INTERVAL '1 day',
-    migrate_data        => true);
-
-COMMENT ON TABLE enforcement IS 'Enforcements represent rule triggering by events (TimescaleDB hypertable partitioned on created)';
-
--- ============================================================================
--- CONVERT EXECUTION TABLE TO HYPERTABLE
--- ============================================================================
--- Executions are updated ~4 times during their lifecycle (requested → scheduled
--- → running → completed/failed), completing within at most ~1 day — well before
--- the 7-day compression window. The `updated` column and its BEFORE UPDATE
--- trigger are preserved (used by timeout monitor and UI).
---
--- No FK constraints reference execution(id) — inquiry.execution,
--- workflow_execution.execution, execution.parent, and execution.original_execution
--- were all created as plain BIGINT columns in migrations 000005 and 000006.
---
--- The existing execution_history hypertable and its trigger are preserved —
--- they track field-level diffs of each update, which remains valuable for
--- a mutable table.
--- ----------------------------------------------------------------------------
-
-ALTER TABLE execution DROP CONSTRAINT execution_pkey;
-ALTER TABLE execution ADD PRIMARY KEY (id, created);
-
-SELECT create_hypertable('execution', 'created',
-    chunk_time_interval => INTERVAL '1 day',
-    migrate_data        => true);
-
-COMMENT ON TABLE execution IS 'Executions represent action runs with workflow support (TimescaleDB hypertable partitioned on created). Updated ~4 times during lifecycle, completing within ~1 day (well before 7-day compression window).';
+COMMENT ON TABLE enforcement IS 'Enforcements represent rule triggering by events';
+COMMENT ON TABLE execution IS 'Executions represent action runs with workflow support. History and analytics are stored in execution_history.';
 
 -- ============================================================================
 -- TRIGGER FUNCTIONS
@@ -410,22 +366,6 @@ ALTER TABLE event SET (
 );
 SELECT add_compression_policy('event', INTERVAL '7 days');
 
--- Enforcement table (hypertable)
-ALTER TABLE enforcement SET (
-    timescaledb.compress,
-    timescaledb.compress_segmentby = 'rule_ref',
-    timescaledb.compress_orderby = 'created DESC'
-);
-SELECT add_compression_policy('enforcement', INTERVAL '7 days');
-
--- Execution table (hypertable)
-ALTER TABLE execution SET (
-    timescaledb.compress,
-    timescaledb.compress_segmentby = 'action_ref',
-    timescaledb.compress_orderby = 'created DESC'
-);
-SELECT add_compression_policy('execution', INTERVAL '7 days');
-
 -- ============================================================================
 -- RETENTION POLICIES
 -- ============================================================================
@@ -433,8 +373,6 @@ SELECT add_compression_policy('execution', INTERVAL '7 days');
 SELECT add_retention_policy('execution_history', INTERVAL '90 days');
 SELECT add_retention_policy('worker_history', INTERVAL '180 days');
 SELECT add_retention_policy('event', INTERVAL '90 days');
-SELECT add_retention_policy('enforcement', INTERVAL '90 days');
-SELECT add_retention_policy('execution', INTERVAL '90 days');
 
 -- ============================================================================
 -- CONTINUOUS AGGREGATES
@@ -449,6 +387,8 @@ DROP MATERIALIZED VIEW IF EXISTS event_volume_hourly CASCADE;
 DROP MATERIALIZED VIEW IF EXISTS worker_status_hourly CASCADE;
 DROP MATERIALIZED VIEW IF EXISTS enforcement_volume_hourly CASCADE;
 DROP MATERIALIZED VIEW IF EXISTS execution_volume_hourly CASCADE;
+DROP VIEW IF EXISTS enforcement_volume_hourly CASCADE;
+DROP VIEW IF EXISTS execution_volume_hourly CASCADE;
 
 -- ----------------------------------------------------------------------------
 -- execution_status_hourly
@@ -553,49 +493,35 @@ SELECT add_continuous_aggregate_policy('worker_status_hourly',
 --       instead of a separate enforcement_history table.
 -- ----------------------------------------------------------------------------
 
-CREATE MATERIALIZED VIEW enforcement_volume_hourly
-WITH (timescaledb.continuous) AS
+CREATE VIEW enforcement_volume_hourly AS
 SELECT
-    time_bucket('1 hour', created) AS bucket,
+    date_trunc('hour', created) AS bucket,
     rule_ref,
     COUNT(*) AS enforcement_count
 FROM enforcement
 GROUP BY bucket, rule_ref
-WITH NO DATA;
-
-SELECT add_continuous_aggregate_policy('enforcement_volume_hourly',
-    start_offset    => INTERVAL '7 days',
-    end_offset      => INTERVAL '1 hour',
-    schedule_interval => INTERVAL '30 minutes'
-);
+;
 
 -- ----------------------------------------------------------------------------
 -- execution_volume_hourly
 -- Tracks execution creation volume per hour by action_ref and status.
--- This queries the execution hypertable directly (like event_volume_hourly
--- queries the event table). Complements the existing execution_status_hourly
--- and execution_throughput_hourly aggregates which query execution_history.
+-- This queries the execution table directly. Complements the existing
+-- execution_status_hourly and execution_throughput_hourly aggregates which
+-- query execution_history.
 --
 -- Use case: direct execution volume monitoring without relying on the history
 -- trigger (belt-and-suspenders, plus captures the initial status at creation).
 -- ----------------------------------------------------------------------------
 
-CREATE MATERIALIZED VIEW execution_volume_hourly
-WITH (timescaledb.continuous) AS
+CREATE VIEW execution_volume_hourly AS
 SELECT
-    time_bucket('1 hour', created) AS bucket,
+    date_trunc('hour', created) AS bucket,
     action_ref,
     status AS initial_status,
     COUNT(*) AS execution_count
 FROM execution
 GROUP BY bucket, action_ref, status
-WITH NO DATA;
-
-SELECT add_continuous_aggregate_policy('execution_volume_hourly',
-    start_offset    => INTERVAL '7 days',
-    end_offset      => INTERVAL '1 hour',
-    schedule_interval => INTERVAL '30 minutes'
-);
+;
 
 -- ============================================================================
 -- INITIAL REFRESH NOTE