Re: How to avoid UPDATE performance degradation in a transaction - Mailing list pgsql-performance

From David G. Johnston
Subject Re: How to avoid UPDATE performance degradation in a transaction
Date
Msg-id CAKFQuwYczHCb0ByP=s4_Dyq5m0EcHfS+g9Gg8sx-9ZV+JoH3rA@mail.gmail.com
Whole thread Raw
In response to How to avoid UPDATE performance degradation in a transaction  (Karl Düüna <karl.dyyna@gmail.com>)
List pgsql-performance
On Thu, Feb 13, 2020 at 1:42 PM Karl Düüna <karl.dyyna@gmail.com> wrote:
It really isn't noticeable until about 5k UPDATEs on a single row.

Don't know why, and never dealt with a scenario where this would even come up, but that this doesn't perform well inside a transaction isn't surprising to me.  Kinda surprised it works well at all actually.  I'd probably try and rework the processing algorithm to create an unlogged temporary table with data from the row's initial state, manipulate until my heart's content, then take the final result and update the single live row with the final state.

David J.

pgsql-performance by date:

Previous
From: Karl Düüna
Date:
Subject: How to avoid UPDATE performance degradation in a transaction
Next
From: Tom Lane
Date:
Subject: Re: How to avoid UPDATE performance degradation in a transaction