Re: Thoughts on how to avoid a massive integer update.

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Thoughts on how to avoid a massive integer update.
Date: 2020-05-04 21:57:20
Message-ID: 94454b33-1913-ac3c-3437-73e3a5c29c9a@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5/4/20 3:32 PM, Fehrle, Brian wrote:
>
> Hi all,
>
> This is a shot in the dark in hopes to find a magic bullet to fix an
> issue I have, I can’t personally think of any solution myself.
>
> I have a database with hundreds of terabytes of data, where every
> table has an integer column referencing a small table. For reasons out
> of my control and cannot change, I NEED to update every single row in
> all these tables, changing the integer value to a different integer.
>
> Since I have to deal with dead space, I can only do a couple tables at
> a time, then do a vacuum full after each one.
> Another option is to build a new table with the new values, then drop
> the old one and swap in the new, either way is very time consuming.
>
> Initial tests suggest this effort will take several months to
> complete, not to mention cause blocking issues on tables being worked on.
>
> Does anyone have any hackery ideas on how to achieve this in less
> time? I was looking at possibly converting the integer column type to
> another that would present the integer differently, like a hex value,
> but everything still ends up requiring all data to be re-written to
> disk. In a well designed database (I didn’t design it :) ), I would
> simply change the data in the referenced table (200 total rows),
> however the key being referenced isn’t just an arbitrary ID, it’s
> actual ‘data’, and must be changed.
>
> Thanks for any thoughts or ideas,
>
> * Brian F
>
Is the new value computable from the original value with a single
function? Could you cover your tables with viewa transforming the column
with said function?

No?  You'll need to divorce each table from that lookup table and any
foreign key relationships to avoid all those lookups with ever update.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Peter 2020-05-04 22:01:32 Re: 12.2: Howto check memory-leak in worker?
Previous Message Adrian Klaver 2020-05-04 21:56:26 Re: Thoughts on how to avoid a massive integer update.