The query is the one sitting behind every "current status" tile: latest reading for one device, `ORDER BY time DESC LIMIT 1`, one index scan against the newest chunk, which already has an index on device and time [3]. On a hypertable with a few thousand chunks, TimescaleDB says that query can take tens or hundreds of milliseconds to hand back that single row, and nearly all of it is planning rather than execution [4].
The `LIMIT` does not rescue the planner because the planner cannot trust it. The newest chunk might be empty, or every row in it might fail a filter on a column that is not a dimension, in which case the answer sits in an older chunk and a correct plan has to be able to reach it [10]. Only plan-time pruning takes a chunk out of the plan, and pruning needs a dimension constraint that folds to a constant while planning happens [12]. A predicate on `device` is not one of those.
This is also why `EXPLAIN ANALYZE` has been reassuring in a misleading way. ChunkAppend already visited chunks newest-first, stopped after the first, and printed "never executed" against the rest [11]. What it skipped was the scanning. The executor still set up every chunk's slice of the plan at startup, so chunk count was charged twice, once in planning and once in executor startup [13].
The vendor's fleet number is worth doing the arithmetic on. 1,000 CPU hours a day, divided by 24, is roughly 42 cores doing nothing but planning these queries around the clock [16], or more than 365,000 CPU hours a year [17]. The fix is DeferredChunkAppend, which pulls chunks lazily at execution in the order the query requires, in time order when there is an `ORDER BY` on the time dimension and newest-first when there is not, stopping once the `LIMIT` is met [15]. The post is headlined 14,000x faster planning [2]; the portion explaining the mechanism does not publish the chunk count or workload behind that multiple [19], so it is a best case, not a forecast for your cluster.
Two things decide whether this is urgent. The first is whether the slow query can carry a time predicate at all: `WHERE time > now() - interval '1 hour'` expands only the matching chunks, on whatever version you are running today [7]. The second is the PostgreSQL major version, because 2.28 ends PostgreSQL 15 support [1], and a PG15 cluster therefore cannot get DeferredChunkAppend until the database itself is upgraded [18].
That gives four boxes. Predicate possible, PG16 or later: rewrite the query and treat 2.28 as ordinary maintenance. Predicate possible, PG15: same rewrite, and the version upgrade can be planned at a human pace. Predicate impossible, PG16 or later: this release is the whole point, and it costs a minor bump. Predicate impossible, PG15: the awkward corner, and the honest way in is to run `EXPLAIN ANALYZE` on the offending query first and read planning time against execution time [4]. If planning is a small share of the wall clock, chunk count is not what is hurting you, and 2.28 becomes a deadline to manage rather than a fix to chase.
