| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Mark Zellers <markz(at)adaptiveinsights(dot)com> |
| Cc: | Israel Brewster <ijbrewster(at)alaska(dot)edu>, Rob Sargent <robjsargent(at)gmail(dot)com>, Alban Hertroys <haramrae(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: UPDATE many records |
| Date: | 2020-01-06 21:38:53 |
| Message-ID: | CAHOFxGoLdeWT8ed5pmVEM6QsSQDFPyFkmyEaV1Nt6bNvQ4yYMg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jan 6, 2020 at 2:34 PM Mark Zellers <markz(at)adaptiveinsights(dot)com>
wrote:
> Just out of curiosity, what kind of trigger are you using, a row level
> trigger or a statement level trigger? If you are using a row level
> trigger, see if you can achieve your requirements using a statement level
> trigger instead. I’m relatively new to Postgres, so there could be some
> limit that I’m not aware of, but my understanding is that you have access
> to the old and new values of the updated rows in the after statement
> trigger. It would likely be much more performant to do your operation once
> after the statement is done rather than firing a trigger on every changed
> row.
>
My experience/understanding is that statement level triggers can be a big
performance boost, but only for changing *other* tables and not the table
that the trigger is on since it is *AFTER* only and can't modify NEW record
directly.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin | 2020-01-06 21:49:13 | Re: UPDATE many records |
| Previous Message | Andrew Dunstan | 2020-01-06 21:34:34 | Re: jsonb_set() strictness considered harmful to data |