Index Overhead Postgres MVCC mechanism creates a new tuple version when a row is updated. This means that tuple updates, barring hot updates, have an amplifying effect on write load in addition to inserts and deletes, because all indexes that contain a pointer to the old tuple version must also get updated. Updates impose another insidious cost on query performance: index-only scans lose efficiency. If a table’s visibility map is stale due to heavy update volume, then index-only scans must fetch heap pages to confirm tuple visibility, nullifying the benefits of the index-only scan. Then, there is WAL logging. To support physical replication, index changes have to be individually tracked in the WAL file along with the heap change if WAL logging is enabled. This is another cost overhead that requires careful consideration of index use. Consequently, a single tuple operation has the potential to turn into multiple write operations depending on just table indexing choices, everything else ...