From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tobias Gierke <tobias(dot)gierke(at)code-sourcery(dot)de>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Linear slow-down while inserting into a table with an ON INSERT trigger ? |
Date: | 2021-07-17 14:33:09 |
Message-ID: | 62962.1626532389@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Sat, 17 Jul 2021 at 16:40, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>> You could run a single UPDATE rather than 30k triggers.
>> Or switch to an INSERT on the table, with an index on it, and call
>> max(last_parent_table_change) from whatever needs to ingest it. And prune the
>> old entries and vacuum it outside the transaction. Maybe someone else will
>> have a better suggestion.
> Maybe just change the UPDATE statement to:
> UPDATE data_sync SET last_parent_table_change=CURRENT_TIMESTAMP WHERE
> last_parent_table_change <> CURRENT_TIMESTAMP;
> That should reduce the number of actual updates to 1 per transaction.
Or, if it's impractical to make the application do that for itself,
this could be a job for suppress_redundant_updates_trigger().
https://www.postgresql.org/docs/current/functions-trigger.html
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ninad Shah | 2021-07-18 06:52:00 | Re: Linear slow-down while inserting into a table with an ON INSERT trigger ? |
Previous Message | David Rowley | 2021-07-17 07:02:31 | Re: Linear slow-down while inserting into a table with an ON INSERT trigger ? |