| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | AJG <ayden(at)gera(dot)co(dot)nz>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Trigger overhead/performance and alternatives? |
| Date: | 2018-07-07 07:47:47 |
| Message-ID: | 0ebffecc-6f25-0436-2a0b-f6049a5cb4a6@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 01.07.18 11:31, AJG wrote:
> Where is mentioned trigger overhead, and provided an alternative solution
> (logical replication slot monitoring).
>
> My 2 part question is.
>
> 1) Does anybody have any benchmarks re: trigger overhead/performance or have
> any experience to give a sort of indication, at all?
That really depends on a lot of things, how you write the triggers, what
they do, etc. You should probably measure that yourself.
> 2) Is anybody aware of any other clever alternatives, pg extensions or
> github code etc as an alternative to using triggers?
Maybe wal2json will give you a starting point.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-07-07 20:01:58 | Re: Faster str to int conversion (was Table with large number of int columns, very slow COPY FROM) |
| Previous Message | Justin Pryzby | 2018-07-05 03:56:36 | Re: tcp_keepalives |