Warum puffert eine SELECT-Anweisung den Cache in Postgres?

Ich laufe EXPLAIN (ANALYZE, BUFFERS) SELECT ...auf meinem Postgres 9.3-Server. Am Ende sehe ich so etwas wie Buffers: shared hit=166416 dirtied=2in der Ausgabe.
Aus der Dokumentation geht hervor , dass "schmutzig":

Die Anzahl der verschmutzten Blöcke gibt die Anzahl der zuvor unveränderten Blöcke an, die durch diese Abfrage geändert wurden. Die Anzahl der geschriebenen Blöcke gibt die Anzahl der zuvor verschmutzten Blöcke an, die von diesem Backend während der Abfrageverarbeitung aus dem Cache entfernt wurden.

Dies klingt für mich so, als ob der Vorgang des Markierens eines verschmutzten Blocks nur beim Aktualisieren von Daten stattfinden sollte. Meine Abfrage ist jedoch eine SELECTund liest nur Daten. Ich würde mir vorstellen, dass nur Treffer oder Lesungen gemeldet werden. Ich irre mich offensichtlich. Was genau passiert in dieser Situation?

Dies hat einen einfachen Grund.

In PostgreSQL muss eine Zeile eine Sichtbarkeitsprüfung durchlaufen. Beim ersten Lesen prüft das System, ob eine Zeile für alle sichtbar ist. Wenn dies der Fall ist, wird es "eingefroren". Hierher kommen die Schriften. In ähnlicher Weise werden VACUUMauch Bits gesetzt.

Es gibt eine ausführliche Erklärung: http://www.cybertec.at/speeding-up-things-with-hint-bits/ .