fix: more aggressive conversion to columnstore

migrations/2025-12-08-235657_adjust_compression_policy_schedule/down.sql

···
+-- Revert compression policy to original schedule
+--
+-- This reverts to the original settings:
+--   - Run daily (every 1 day)
+--   - Compress chunks older than 2 days
+
+-- Revert schedule to daily
+SELECT alter_job(1000, schedule_interval => interval '1 day');
+
+-- Revert compress_after to 2 days
+-- 2 days = 2 * 86400 seconds = 172,800 seconds
+-- In TID format: 172,800 * 1,000,000 microseconds << 10 = 176,947,200,000,000 ticks
+SELECT alter_job(1000,
+    config => jsonb_set(
+        (SELECT config FROM timescaledb_information.jobs WHERE job_id = 1000),
+        '{compress_after}',
+        to_jsonb((2::bigint * 86400 * 1000000::bigint << 10)::text)
+    )
+);

migrations/2025-12-08-235657_adjust_compression_policy_schedule/up.sql

···
+-- Adjust compression policy to run more frequently with shorter compress_after
+--
+-- CHANGE: Update existing compression policy (job 1000) to:
+--   - Run every 10 minutes (instead of daily)
+--   - Compress chunks older than 4 hours (instead of 2 days)
+--
+-- RATIONALE: With larger chunk sizes, we want to compress
+-- chunks that are no longer receiving active writes. Since chunks span multiple
+-- days, setting compress_after to 4 hours ensures we compress all but the latest
+-- active chunk, while running every 10 minutes ensures timely compression.
+
+-- Change schedule to run every 10 minutes
+SELECT alter_job(1000, schedule_interval => interval '10 minutes');
+
+-- Change compress_after to 4 hours
+-- 4 hours = 4 * 3600 seconds = 14,400 seconds
+-- In TID format: 14,400 * 1,000,000 microseconds << 10 = 14,745,600,000,000 ticks
+SELECT alter_job(1000,
+    config => jsonb_set(
+        (SELECT config FROM timescaledb_information.jobs WHERE job_id = 1000),
+        '{compress_after}',
+        to_jsonb((4::bigint * 3600 * 1000000::bigint << 10)::text)
+    )
+);

migrations/2025-12-09-000126_fix_timescaledb_compression_policy/down.sql

···
+-- Reverse the integer_now function setup
+-- This will cause compression policy to fail again, but allows rollback if needed
+
+-- Remove the integer_now function from the posts hypertable
+SELECT set_integer_now_func('posts', NULL);
+
+-- Drop the tid_now function
+DROP FUNCTION IF EXISTS public.tid_now();

migrations/2025-12-09-000126_fix_timescaledb_compression_policy/up.sql

···
+-- Fix TimescaleDB compression policy by setting integer_now function
+--
+-- PROBLEM: The compression policy fails with "integer_now function not set"
+-- because the posts table uses integer-based time (TID/rkey), and TimescaleDB needs
+-- to know how to calculate "now" in TID units to determine which chunks to compress.
+--
+-- SOLUTION: Create and register a function that converts current time to TID format.
+
+-- Create function that returns current timestamp as TID
+-- TID format: (microseconds_since_epoch << 10)
+-- This matches the tid_now() function already used elsewhere in the codebase
+CREATE OR REPLACE FUNCTION public.tid_now() RETURNS BIGINT AS $$
+  SELECT (EXTRACT(EPOCH FROM NOW()) * 1000000)::BIGINT << 10;
+$$ LANGUAGE SQL STABLE;
+
+-- Register the function with the posts hypertable
+-- This allows TimescaleDB compression policies to work with integer-based time
+SELECT set_integer_now_func('posts', 'tid_now');
+
+-- Note: The existing compression policy (job_id 1000) will now start working
+-- It compresses chunks based on the compress_after configuration
+-- The policy runs on a scheduled interval and converts old chunks from rowstore to columnstore format