| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Karl Düüna <karl(dot)dyyna(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: How to avoid UPDATE performance degradation in a transaction |
| Date: | 2020-02-13 20:50:38 |
| Message-ID: | CAKFQuwYczHCb0ByP=s4_Dyq5m0EcHfS+g9Gg8sx-9ZV+JoH3rA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Feb 13, 2020 at 1:42 PM Karl Düüna <karl(dot)dyyna(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-02-13 21:16:14 | Re: How to avoid UPDATE performance degradation in a transaction |
| Previous Message | Karl Düüna | 2020-02-13 10:21:17 | How to avoid UPDATE performance degradation in a transaction |