Zola 2024-12-21T00:00:00+00:00 https://jesipow.com/atom.xml 2024-12-21T00:00:00+00:00 2024-12-21T00:00:00+00:00 Alex jesipow https://jesipow.com/blog/postgres-reads-cause-writes/

<p>It is good practice to regularly inspect the statements running in the hot path of your Postgres instance. One way to do this is to examine the <code>pg_stat_statements</code> <a rel="noopener" target="_blank" href="https://www.postgresql.org/docs/current/pgstatstatements.html">view</a>, which shows various statistics about the SQL statements executed by the Postgres server.</p> <p>Among many other interesting columns, you will find the <code>shared_blks_dirtied</code> and <code>shared_blks_written</code> columns. They keep track of how many blocks, Postgres' smallest unit of I/O, in the shared buffer cache are modified by a statement and (ultimately) written to disk.</p> <p>One observation you may make when inspecting the view is that <code>SELECT</code> queries show non-zero values in the <code>shared_blks_written</code> and <code>shared_blks_dirtied</code> columns. This seems counterintuitive at first as it indicates that a simple <code>SELECT</code> query, which you would expect to only read data, can in fact cause data to be written (keeping track of the statement statistics themselves is not what causes these writes).</p> <p>This article discusses two mechanisms, setting hint bits for transaction state tracking and page pruning, that can cause writes by read-only statements. Before we can go into detail about these mechanisms themselves, however, we first have to understand how Postgres organises table data and manages concurrency.</p>