The slow phase is the planner, and the index you add makes it slower

The per-partition cost is bookkeeping, not arithmetic. Before the planner can rule a partition out, it takes a lock on the relation, loads its relcache entry and builds planner state for it ^[10]. That happens for every partition in the table, so the bill tracks how many partitions exist rather than how many survive pruning ^[10].

Do the division nobody in the plan output does for you. Twenty thousand planning blocks across 500 partitions is about 40 blocks each, roughly 321 KB of metadata touched to open and price a chunk that is then thrown away ^[7]. The scan that actually answered the question read 898 heap blocks ^[20], something in the order of 7 MB ^[4]. And planning was 89.7 percent of the 70.1 ms the statement spent end to end ^[6].

The awkward part is that the plan was good. Pruning left a single partition, the bitmap scan hit cache on every block, and the row estimate came in within three percent ^[9]. A reviewer walking the plan tree from the top finds nothing to fix in it, which is precisely the state in which someone reaches for an index ^[18]. Timescale's own framing is that this ends in weeks spent optimizing the phase that was never slow ^[19].

None of this makes the optimizer overhead waste. On a warehouse query with eight joins, the same post notes, the optimization pass pays for itself many times over ^[15], and execution time still scales with heap pages read, hashing, sorting and aggregating rather than with how many plans were weighed ^[16]. Partition count is what breaks the trade, because the setup is charged whether or not pruning ends up needing it ^[10].

Treat the absolute milliseconds with suspicion. This is one vendor's synthetic device_metrics table on PostgreSQL 16.13, 2.1 billion rows in 500 daily chunks, with work_mem at 4 MB and shared_buffers at 256 MB ^[4]. Those settings are small enough that a real fleet will produce different figures. The ratio is the portable part, and the source's instruction is cheap either way: read the last two lines before the tree ^[21], then read the two Buffers lines against each other, because a planner touching more pages than the scan has already named the phase worth working on ^[6].