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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: "Fehrle, Brian" <bfehrle(at)comscore(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Thoughts on how to avoid a massive integer update.
Date: 2020-05-08 20:57:03
Message-ID: CAKFQuwbeTJitNUMasKtjTopbs-bcVurvPVth9oTACGRVKhCKAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 8, 2020 at 1:51 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:

>
> On May 8, 2020, at 2:43 PM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> wrote:
>
> On Fri, May 8, 2020 at 1:41 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
>> My understanding is the keys in the info_table need to change. That
>> causes the very expensive update in the update in the data tables. No?
>>
>
> The keys in the info_table need to change because their contents are no
> longer legal to be stored (OP has not specified but think using an integer
> value of someones social security number as a key). The FK side of the
> relationship equality has the same illegal data values problem and need to
> be changed too.
>
> Wow, I couldn’t disagree more ;)
>

Your agreement or disagreement with the problem statement is immaterial
here - the OP has stated what the requirement, for which I have made a
simplistic analogy in order to try and get the point across to you. As the
OP has said it is a poor design - and now it is being corrected. The
request is whether there is some way to do so better than the two options
the OP already described.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2020-05-08 21:05:08 Re: Thoughts on how to avoid a massive integer update.
Previous Message Support 2020-05-08 20:51:48 Reuse an existing slot with a new initdb