Re: UPDATE many records

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: Israel Brewster <ijbrewster(at)alaska(dot)edu>, 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 20:40:39
Message-ID: 9BB7DDC4-16D7-4137-8F6A-5C4F4F7AB2A0@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Jan 6, 2020, at 1:29 PM, Alban Hertroys <haramrae(at)gmail(dot)com> wrote:
>
> I think you’re overcomplicating the matter.
>
> I’d just do it as a single update in one transaction. It’s only 50M rows. It may take half an hour or so on decent hardware, depending on how resource-intensive your function is.
>
I must emphasize: This estimate is HIGHLY dependent on hardware and the complexity of the table (number of indices, etc). (I suspect there’s a correlation between table size (business value) and number of indices)

> If that fails[1], only then would I start looking into batching things. But then you still need to figure out why it fails and what to do about that; if it fails it will probably fail fast, and if not, then you’re looking at a one-off situation that won’t require more than a few workarounds - after which you can just run the update again.
>
> Ad 1). No harm has been done, it’s a single transaction that rolled back.
>
> Alban Hertroys
> --
> If you can't see the forest for the trees,
> cut the trees and you'll find there is no forest.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Israel Brewster 2020-01-06 20:47:17 Re: UPDATE many records
Previous Message Christopher Browne 2020-01-06 20:38:02 Re: UPDATE many records