The hourly refresh ceiling the compression phase grid is sized against is 594s, and the job has since run 702s, 815s and 871s

[erikdarlingdata]

TimescaleSupport.HeaviestHourlyRefreshObservedCeilingSeconds is 594, pinned by RefreshCeilingProvenancePinTests to the maximum of a published 16-run population (194 s–594 s, mean 352.5, median 345) for policy_refresh_continuous_aggregate query_store_stats_interval_hourly (job 1054).

Three runs since then exceed it, read from the store's own job telemetry:

when	duration	vs the pinned ceiling
2026-09-07 00:00 hour	702 s	1.18×
2026-09-07 21:00 hour	871 s	1.47×
2026-09-08 00:00 hour	815 s	1.37×

get_store_metrics currently reports this job at last_run_duration_ms = 815116, duty_vs_cadence = 22.6%, 375 runs, 2 failures — the only policy on the store with failures other than policy_telemetry.

This is the constant's own pre-registered trigger, not a new opinion

Its summary states the limitation and what would invalidate it:

What would change that answer … or this maximum ceasing to be a lower bound on the truth. The second is the live limitation, and it is a property of the READ rather than of the estimator: the boundary day's runs are a census of that day after the boundary, while the days after it are a SAMPLE …

It also names the census read that settles it rather than leaving it implied: timescaledb_information.job_history, whose succeeded column this store has because DarlingManagedPostgres.BuildConfAppend enables timescaledb.enable_job_execution_logging (#1681) — read as every run since the boundary rather than sampled, giving count, median and maximum each side of it.

The grid is NOT breached, and the margin is what changed

Stating this explicitly because it is the mistake to avoid: RefreshPhaseSlotSeconds is 900 s (RefreshPhaseStepMinutes = 15), and 871 s fits. Nothing has overrun its slot.

What has changed is the clearance. The doc deliberately presents the bound and its margin as two numbers — RefreshPhaseSlotSeconds minus the ceiling — so:

	seconds
slot	900
ceiling as pinned	594
clearance today	306
clearance if the population is re-derived at 871	29

And 871 s is already above RefreshSlotWarningSeconds (900 × 5/6 = 750 s), which is the product's own signal that a slot is being consumed.

So the ask is not "raise the constant" — it is: re-derive the population by the method the doc records, using the named census read, and then decide whether 15-minute slots still hold. TimescaleSupportTests holds the grid clear of this constant, so a re-derivation to 871 may redden it, which is the check working rather than a problem with the check.

What I am NOT claiming

I found these runtimes while looking for the mechanism behind #3112's lag band, and I got the mechanism wrong twice before the arithmetic corrected me — first as "the policies are not staggered" (they are, by an initial_start phase grid), then as "the grid's ceiling is breached" (it is not; 871 fits in 900). I am not asserting this explains #3112. The band's own scoring is on #3112 and this issue is only the calibration observation, which stands on its own regardless of what #3112 turns out to be.

One adjacent observation, recorded without a claim attached: the hourly compression policies on the same hypertable family have last-run durations of 552 s (query_store_stats), 360 s (query_stats) and 198 s (query_snapshots), all well above OtherHourlyRefreshObservedCeilingSeconds (140 s). Whether a compression run of that length crossing an adjacent phase boundary matters is a question for whoever owns the grid — the doc says non-heaviest slots are "treated as occupied only at their start", and I do not know whether that reasoning was meant to cover compression runtimes of this size.

Related: #3035 (the phase grid), #3101 (deriving a constant as a method), #3012, #3112.

[erikdarlingdata]

Claude posting for Erik Darling

Two corrections to this issue as filed, both from the product's own record.

1 — My duration figures are readings, not maxima, and the product says so explicitly. The TimescaleSupport alert at the watch line states it directly:

Its per-run history is timescaledb_information.job_history, one row per run; the hourly collect.store_metrics series (object_kind = 'background_job') samples one reading an hour and serves a daily point that is the day's LAST, so neither answers a maximum question (#3044, #3119).

The 815 s in the table above came from exactly that series via get_store_metrics. So it is one sampled reading, and the daily point is a last, not a max — the figure cannot bound the population and the real maximum may be higher. The 702 s and 871 s came from per-run job detail rather than the series and are genuine observations, but they are still a sample, not a census.

This does not weaken the issue — it is the reason the census read matters, and the lane on this is already directed at job_history with succeeded. It does mean no number in this issue should be treated as the ceiling until that census runs.

2 — The product already alerts on this, at two thresholds, and names the fix space. I filed as though this were unsurfaced. It is not. TimescaleSupport.cs carries both a watch-line alert and a slot-breach alert, and the breach text pre-states the answer:

it no longer fits inside its own slot, so excluding one slot is no longer enough and the compression phase grid's stated precondition is false. The grid has to be RE-DERIVED (#3035), not renumbered: a 15-minute grid can no longer hold thirteen hourly refreshes, so the fix is fewer slots, a longer cadence for this aggregate, or splitting it (#3044).

So "re-derive, don't renumber" is the product's own instruction, and 871 s is already past the 750 s watch line. Whether either alert has actually fired, I could not establish — a 50-row fleet alert history over 30 hours came back covering roughly one hour, because collector-cost-regression alerts saturate the window. That is a truncated instrument, not evidence of absence, and I am not claiming either way.

Related, and pointing at a bigger mechanism than this issue holds: the midnight band's mechanism has now been named independently — the daily chunk-close burst meeting the refresh grid at the shared midnight boundary, which is #3041's documented load-dependent residual measured at n=2 with clock-level reproduction. At every other hour the compression ticks at :22–:29 / :37–:44 / :52–:59 find nothing eligible and finish in seconds; at 00:00Z every hypertable's newest 1-day chunk closes at once, so those same ticks carry a full day's compression and overrun into the next refresh's start. That belongs to #3112 rather than here, and this issue's calibration question stands on its own either way.

[erikdarlingdata]

Claude posting for Erik Darling

Closed by PR #3178 (which absorbed #3168's work), merged to dev. Closing by hand.

The re-derivation this issue asked for is in: the ceiling moves 594 → 896, from a timescaledb_information.job_history census read by the method the constant's own doc records — positional exclusion rule, estimator the maximum, and the 95th-percentile clause removed with the argument it guarded now that n=57 makes the 95th 830 s rather than the maximum.

But the finding is that the grid was mis-shaped, not mis-stepped, so this closes into #3174's redesign rather than as a constant bump. Other*4 < Heavy is red at every step because it contains no step term — 226 x 4 = 904 > 896 — and the two prose claims it pinned ('under a quarter of it', 'more than 4x') were false at 25.2% and 3.96x. Those sentences were the justification for the grid's shape.

OtherHourlyRefreshObservedCeilingSeconds moved to 226.8 without excluding the midnight regime, per its own doc: 'NOTHING IS SIZED FROM IT ... this figure only says how much margin that derivation happens to leave.' It is a readout of the margin, so it must include the runs where the margin was consumed — I argued the opposite earlier and was wrong.

The census is scoped to its store: 874 runs across 12 views, read before #3177 healed the job_history GUC, so the scope is a property of the read and is stated on the constant. Two largest both at 00:30 — 226.8 vs 160.4, +41% night over night — and the third largest reproduces the old 140 exactly at 140.1 s.