Mysteriously varying index scan costs

Last week I encountered the following at a customer site on PostgreSQL 9.6,
and I cannot explain it.

The first run gave me this:

Index Scan using device_outbound_messages_status on device_outbound_messages (cost=0.43..20.46 rows=97 width=128) (actual time=34.021..35.545 rows=133 loops=1)
Index Cond: ((status)::text = ANY ('{WAITING_FOR_TX,WAITING_FOR_IMMEDIATE_TX}'::text[]))
Buffers: shared hit=74917 dirtied=707

Subsequent runs of the same query gave me:

Index Scan using device_outbound_messages_status on device_outbound_messages (cost=0.43..20.46 rows=97 width=128) (actual time=2.129..3.907 rows=133 loops=1)
Index Cond: ((status)::text = ANY ('{WAITING_FOR_TX,WAITING_FOR_IMMEDIATE_TX}'::text[]))
Buffers: shared hit=1185

There were no concurrent changes to the data (test environment).
This was part of a bigger statement.

I understand that some pages can be dirtied because table fetches that
cause hint bits to be set.

But how can it be that the first run has to touch 74917 blocks,
while whe second run only needs to touch 1185?

Thanks for any ideas!

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com