| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Andrew Bartley <ambartley(at)gmail(dot)com> |
| Cc: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Performance opportunities for write-only audit tables? |
| Date: | 2018-05-24 21:17:46 |
| Message-ID: | CAKFQuwaCw9ZVXw_YerWVbReEKcQW4uj2q3O5WuQj=ntpAp2Frw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thursday, May 24, 2018, Andrew Bartley <ambartley(at)gmail(dot)com> wrote:
> Hi,
>
> The two main techniques we use are.
>
> The idea here is to backup the rest of your DB to one backup regime and
> the log tables to another. We set it up so at the end of the day the
> current log table is backed up and loaded into an backup archive, then we
> vacuum freeze the log table.
>
Yeah, doing logging in-database for immediate performance while
periodically copying or moving said data to external storage seems like the
best option. Depends on the definition of an acceptable process and
response time should the audit data be needed though.
>
> 2. Use UNLOGGED in the log table creates.
>
Seriously? For audit tables?
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Bartley | 2018-05-24 21:42:06 | Re: Performance opportunities for write-only audit tables? |
| Previous Message | Andres Freund | 2018-05-24 21:17:38 | Re: found xmin from before relfrozenxid on pg_catalog.pg_authid |