Hi, I personally don't like the solution from https://wiki.postgresql.org/wiki/Audit_trigger and here are the reasons why: * it produces a large table where all the changes, from all tables and schemas go - audit.logged_actions. So when you would like to read it to check anything it will be super slow * On audit table are 3 indexes - which slow down the insert process * All the data are kept in one column - so when comes to any analysis you need custom functions to do it
Besides: Why there is fillfactor=100? That's the default value for table, isn't it? I use a bit different approach: * every table has got separate table in a audit schema * audited data are partinioned (usually per month) * it's much easier to remove old data - just by dropping partition * data has got exactly the same structure as in original schema Every od those solution has got pros and cons but I prefer the second one a lot more. You can find one of it here: https://github.com/AwdotiaRomanowna/pgaudit -- View this message in context: http://www.postgresql-archive.org/Audit-based-on-role-tp5976507p5976641.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
