The problematic row has likely received many hot updates (100k+). Could this be a likely explanation for the high execution time?
Query immediately after the bulk updates before VACUUM will take longer time. Since the VACUUM might have cleared the dead tuples and might have updated the hint-bits, the query's execution time has become much better.
As the updates are hot, you may not need to consider other factors like, table size growth and if the indexes have grown in size.
Over the weekend we experienced that lookups using the primary key index (‘konto_pk’) became very slow, in the region 2-3s for fetching a single record:
QUERY PLAN
Index Scan using konto_pk on konto (cost=0.42..6.44 rows=1 width=164) (actual time=0.052..2094.549 rows=1 loops=1)
Index Cond: (id = 2121172829)
Planning time: 0.376 ms
Execution time: 2094.585 ms
After a manual Vacuum the execution time is OK:
QUERY PLAN
Index Scan using konto_pk on konto (cost=0.42..6.44 rows=1 width=164) (actual time=0.037..2.876 rows=1 loops=1)
Index Cond: (id = 2121172829)
Planning time: 0.793 ms
Execution time: 2.971 ms
So things are working OK again, but we would like to know what may cause such a degradation of the index scan, to avoid this happening again? (We are using Postgresql version 9.4.4)