pg_stat_*_columns? - Mailing list pgsql-hackers

From Joel Jacobson
Subject pg_stat_*_columns?
Date
Msg-id CAASwCXfGwXCRXthoT5D50NhZqTq=RrTQQmdQ3MGZL2Y1=D5yPw@mail.gmail.com
Whole thread Raw
Responses Re: pg_stat_*_columns?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: pg_stat_*_columns?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Would others find it useful to see per column statistics about accesses to specific columns?

Two possible use-cases: (maybe there are more?)

1. I think it would be helpful for DBAs to better understand their own system.
Finding unused *tables* is today easy thanks to pg_stat_*_tables, but knowing if something is accessing a *column* or not is not easy.
In my case all our database access is via sprocs, so I can just grep the source code for the column name to see if something is using it, but most DBAs probably don't have that luxury.

2. It could also be useful for audit trailing, if you want to know what a query did, i.e. what tables/columns were accessed in the txn.

Here is an idea of a very simple audit trailing system that would probably fulfill my own needs:

Imagine if we had pg_stat_xact_user_columns and for each committed txn, do an insert to an unlogged table with the same structure as pg_stat_xact_user_columns with the addition of session_user and timestamp for the txn.

I would much rather have audit trailing in a nice table than in a text file. Maybe a foreign data wrapper could be used to ship the audit trail data to some other external append-only pg-database, if the purpose of the audit trailing is to prevent an evil DBA from doing evil things. But for others it might be sufficient to do audit trailing to the same database, for convenience purposes.

In summary:

Some users might only be interested in the statistics and mostly use pg_stat_user_columns.
Other others might also be interested in what happened in a specific txn and use pg_stat_xact_user_columns.
Yet some other users might be interested in audit trailing and want to log pg_stat_xact_user_columns for each txn. Probably very expensive performance wise, but might make sense if you have extremely sensitive data and audit trailing is more important than performance.

Thoughts?

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Next
From: Robert Haas
Date:
Subject: Re: RFC: Remove contrib entirely