Making reads of personal-data tables visible to the team reduces broad queries against those tables

Hypothesis

Access to tables holding personal data is usually controlled by grants and sometimes by row-level policies. Those controls do not change how people with legitimate access query the data: an engineer debugging a ticket runs SELECT * on the users table, an analyst joins the whole table instead of the rows needed. The hypothesis is that visibility alone changes this behaviour. PostgreSQL's log_statement parameter controls which SQL statements are logged, and a per-table digest of the log needs no new enforcement. The claim is that when every read against designated personal-data tables is logged with the role that ran it and summarised to the team weekly (who read which table, how many rows, with or without a person-level predicate), the share of broad reads falls, without a fall in the narrow reads the work requires. The proposed mechanism is not fear of audit but the concreteness of seeing one's own name next to "all rows of users" in a digest read by colleagues.

Prediction

Comparing the eight weeks before the digest is introduced with the eight weeks after, with logging running throughout: the share of statements against the designated tables that have no predicate on a person identifier, or that select all columns, falls; the count of statements with a person-level predicate stays within its previous range; rows returned per statement fall. The effect is largest for interactive sessions by engineers and smallest for scheduled jobs, whose queries were written once. If the broad-read share does not fall, or narrow reads fall in the same proportion (people simply querying less), the hypothesis is false.

Proposed test

1. Designate the tables, enable statement logging for the roles that can read them, and parse the log into records: role, table, presence of a person-level predicate, column wildcard, session type. The statement log carries no row count; rows per statement and role come from the rows column of pg_stat_statements.
2. Run logging for eight weeks without publishing anything, to establish the baseline; tell the team that logging exists, since the test is about visibility, not secret monitoring.
3. Start a weekly digest to the whole team listing, per role, the counts above; continue for eight weeks.
4. Compare the two periods on the measures in the prediction, per role and per session type; report counts, not only shares.
5. Ask the team afterwards which queries they changed and why, to separate behaviour change from workload change.

Status

No result is claimed. Announcing the logging in step 2 may itself change behaviour before the digest exists, which would shrink the measured effect; the workload may also change for unrelated reasons across four months, which is why narrow reads are tracked as a control.