Első olvasatra talán ellentmondásosnak tűnik a cím, de amint e rövid írásból kiderül, a PostgreSQL lekérdezés esetén elkerülhetetlenül ír is az adatbázisba. A kiírt adatmennyiség lehet elenyésző, de lehet igen jelentős is. Nézzünk meg néhány példát.

Az adatbázisba írásért alapvetően két háttérfolyamat felel. Az egyik a background writer, amely a memóriában (shared_buffers) módosított adatblokkokat (dirty pages) írogatja vissza a lemezen lévő adatfájlokba. A másik pedig a checkpointer, amely az összes módosított blokkot kiírja az adatfájlokba.

Kevésbé ismert viszont, hogy a klienseket kiszolgáló folyamatok (client backends) is szoktak írni az adatfájlokba. Ilyen akkor történik például, ha egy lekérdezés során az adatfájlokból felolvasandó adatblokkok már nem férnek el a memóriában (shared buffers), ezért helyet kell csinálni nekik. Ehhez ki kell írni a memóriából az adatfájlokba néhány módosított blokkot (diry pages), hogy azok helyére az újakat lehessen beolvasni.

Tehát csak olvasni szeretnénk az adatbázisból, mégis írásra kényszerítjük a szervert. Ha gyakran történik ilyen, akkor érdemes lehet a shared buffers méretét megnövelni.

A klienseket kiszolgáló folyamatok (client backends) az általuk végzett olvasások végeztével statisztikát küldenek a statistics collector háttérfolyamatnak, amely összegyűjti, összegzi és tárolja azokat. A statisztikák a pg_stat_* katalógusokból kérdezhetők le. Ilyen statisztika például egy tábla teljes végigolvasásainak száma (pg_stat_all_tables.seq_scan), vagy index mentén történő olvasásainak száma (pg_stat_all_tables.idx_scan). Tehát ha csupán lekérdezünk az adatbázisból, a statisztikagyűjtés akkor is generál írási művelet, noha nem sokat.

Az adatbázistáblák minden sorához tárolja a rendszer, hogy melyik tranzakció hozta létre, és melyik módosította az adott sort. Minden egyes sorhoz tartoznak továbbá ún. hint bitek, amelyek azt jelzik, hogy az adott sort létrehozó vagy módosító tranzakció lezárult-e már committal vagy aborttal. Ez az információ ahhoz szükséges, hogy gyorsan lehessen ellenőrizni, hogy a létrejött vagy módosult sorok láthatók-e más tranzakciók számára.

Ha egy táblát módosító tranzakció véget ér, ez a tény bekerül az ún. commit logba. A hint bitek által tárolt információk is a commit logból származnak. A commit logból olvasás viszont extra művelet, ezért az adatbázis az adatblokkokban is tárolja ezeket az információkat, hogy ezáltal a láthatósági ellenőrzést gyorsabban el tudja végezni.

A hint bitek frissítése úgy történik, hogy egy módosított adatblokkokból történő első olvasás során a commit logban lévő információ beíródik az olvasott sorok hint bitjeibe is. Tehát ezúttal is azzal szembesülünk, hogy noha csak olvasunk az adatbázisból, mégis ír a szerver az adatfájlokba. Igaz, csak néhány bitet, de ezáltal módosulnak az érintett adatblokkok.

Az esetleges adatkorrupció korai detektálása érdekében érdemes bekapcsolni azt a funkciót, hogy a PostgreSQL számítson ellenőrzőösszeget az egyes adatblokkokra (data checksums). A data checksums opció bekapcsolása viszont azzal is jár, hogy amikor egy checkpoint művelet után egy adatblokk először módosul, akkor beíródik a blokk teljes tartalma a WAL-ba (Write-Ahead Log, a tranzakciós napló, ami minden módosítást rögzít).

Ez a naplózás megtörténik akkor is, ha csak a hint bitek változtak meg a blokkban, vagyis időközben véget ért a blokkot módosító tranzakció, hiszen a bitek megváltozása miatt is változik a blokk ellenőrző-összege.

Ez tehát azt jelenti, hogy minden olyan blokk első olvasása, amely a legutolsó checkpoint óta változott, WAL-ba írást fog eredményezni. Ez különösen adattárházakból történő lekérdezés esetén jelenthet komolyabb extra I/O-terhelést, hiszen noha csak olvassuk az adatbázist, a legutolsó betöltés óta most olvassuk el először a módosult blokkokat, ami tekintélyes számú írási műveletet eredményezhet.