Your "Index Only Scan" Did 2,847 Heap Fetches: Covering Indexes Are a Vacuum Problem

A workshop published on dev.to by MVP Factory argues that most backend teams read the node type in an execution plan and stop, which is how a covering index ships to production looking healthy and performing exactly like the scan it replaced ^[12]. The post's example plan is the whole argument: an Index Only Scan on `idx_events_covering` returning 50 rows, with `Heap Fetches: 2847` and `Buffers: shared hit=312 read=198` ^[5].

The mechanism is not obscure, it is just easy to skip. Under Postgres MVCC, visibility metadata lives on heap tuples, and an index entry does not carry it ^[1]. Before skipping a heap fetch, the executor consults the visibility map, one bit per heap page, where a set bit asserts that every tuple on that page is visible to all current and future transactions ^[2]. Only a set bit permits the fetch to be skipped ^[3]. VACUUM is what sets those bits, and autovacuum is what runs VACUUM ^[4]. Any UPDATE or DELETE touching a page clears the bit again ^[7].

That is why the index is not the variable. The two plans in the post sit either side of the same index: the degraded one touches 510 buffers, the healthy one touches 14, roughly a 36x difference ^[14]. Divide the fetches by the rows and the degraded plan is doing about 57 heap visits per row it returns ^[15]. The author reports latency in the degraded case as nearly identical to the pre-index query ^[12].

The post's throughput table is where I would slow down. It claims near-zero heap fetch rates below 100 rows/sec, 10 to 40 percent between 100 and 500 rows/sec, 60 to 100 percent above 500, and 100 percent on bulk ETL ingest ^[8]. No methodology, hardware, or table geometry is given for those bands, so treat them as one practitioner's rule of thumb rather than a curve you can plan capacity against. The direction is sound; the digits are not measurements you own.

The prescribed fix is per-table autovacuum overrides: `autovacuum_vacuum_scale_factor` at 0.01 against a default of 0.2, `autovacuum_vacuum_cost_delay` at 2ms, and `autovacuum_vacuum_cost_limit` at 800 against a default of 200 ^[9]. Read those as what they are. The scale factor makes vacuum trigger at one twentieth of the dead-tuple accumulation ^[16], and the cost limit hands each round four times the I/O budget ^[17]. You are buying visibility map freshness with vacuum I/O on a table that is already write-saturated, which is a trade, not a free win.

The part worth adopting immediately is the measurement, not the tuning. The post's query joins `pg_stat_user_tables` with `pg_visibility` to compare all-visible pages against total heap pages, and the read is simple: if `vm_visible_pages` trails `heap_pages`, your index-only scans are paying for heap fetches ^[10]. That needs PostgreSQL 12 or later and access to both views ^[11].

Two things to watch. First, put heap fetches per returned row into whatever you use to review slow queries, because the plan label will not regress when the visibility map goes stale. Second, batch loads: the post's fourth step is headed as forcing VACUUM after batch loads, though the copy supplied here is truncated before the detail ^[13]. An ETL window that leaves every touched page unmarked will degrade the same covering index that behaved perfectly all night.