Pattern 01 — Change Schedule to a Faster Interval
Class: Free
Cost: < 1 second
Test: test_cookbook_01_change_schedule_faster
When to use
Use this pattern when you want stream tables to refresh more frequently — for example, moving from a 1-minute schedule to 10 seconds to reduce analytical latency.
Migration file
-- migrations/streams/hourly_stats.sql
-- @aqueduct:schedule = "10s"
-- @aqueduct:refresh_mode = "FULL"
SELECT region, COUNT(*) AS event_count FROM raw_events GROUP BY region;
Before
# aqueduct.toml excerpt
[targets.prod]
dsn = "${PROD_DSN}"
-- hourly_stats.sql (before)
-- @aqueduct:schedule = "1m"
-- @aqueduct:refresh_mode = "FULL"
SELECT region, COUNT(*) AS event_count FROM raw_events GROUP BY region;
Plan output
Project analytics v3 → v4
Target prod
Changes 1 node affected
~ hourly_stats [free] schedule: 1m → 10s
Why it's Free
pg_trickle stores the schedule as metadata alongside the stream table spec. A schedule
change is a single call to pgtrickle.alter_stream_table(p_schedule => '10s'). No DDL
is emitted, no data is moved, no rebuild is required.
Notes
- Schedules as short as
1sare allowed. Check the pg_trickle documentation for the minimum supported schedule for your cluster. - The
aqueduct lintcommand warns whenschedule < 5son a large table.