Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1su0EB-003Ln6-R4 for pgsql-general@arkaria.postgresql.org; Fri, 27 Sep 2024 01:57:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1su0EA-000S1P-Ar for pgsql-general@arkaria.postgresql.org; Fri, 27 Sep 2024 01:57:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1su0E9-000S1G-UK for pgsql-general@lists.postgresql.org; Fri, 27 Sep 2024 01:57:01 +0000 Received: from mail-qt1-x836.google.com ([2607:f8b0:4864:20::836]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1su0E5-001HXv-2M for pgsql-general@postgresql.org; Fri, 27 Sep 2024 01:57:00 +0000 Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-4582c62ee33so13217311cf.3 for ; Thu, 26 Sep 2024 18:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lji.io; s=google; t=1727402216; x=1728007016; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hEtZEbE5DDdXIcCKfuZ8DzVvqHvAtGRWtL+r+FNV2sw=; b=l6Ue5IkPO2QEu60C5pm3X485BNr4Y2Q9kOpcEDjQy3X97UvPc2D+mfzn4HaU0wQk8S plZVdWMfPwiqgV+Hwr7Fl8juwPFocu8+np9AgA1VS52WzcuExgmubaCex8w5wudXX/Fd SOB/9rs1/TCuSKGqVrMnkYd8eDZ6sP5CS37z4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727402216; x=1728007016; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hEtZEbE5DDdXIcCKfuZ8DzVvqHvAtGRWtL+r+FNV2sw=; b=T5Sj4T70srZb69g0JiF/959xF5/b0uBk/mq0IYSgb4wY8F9aC/TAg86I6mPu569Dtl oI9JEpsTI/CnXo5A+KIawC5Y6FfLXeISQ78YywmlDKs+HFe5Az7r81EPfX3ZPRQOnsdF wlWufntSVOsJDnaOOSl3/QNiDv2SBMIheFRz4/vSgP76Gdo9S+q1a3pLRCz/J33MY2g/ 048TPUbol/gJCZka5SxblePF4xgJOQyzPS3ngFCwjDZFsQrjw5gBnF4wLe1p4iWksnE/ 6pzixcjNr6AaH65RCqawldz+M9KYWz8jVZNWZrAcGfMJRBeb4aFWonInG9XNhu8z/4q7 0ZlQ== X-Gm-Message-State: AOJu0YwnRdPqdMcYv1zmBAyd1W37XBvpkhCVcp9Rvye9vFckKNj4jF56 olfkRIqDBtHfcXcL1FA4mrvcFstBZ1h2FWAXX9DabipiXXF3VIn+LLDF6RZ4WQa5ILu6KIZ59z6 0iBmqKkicpq8dapUWHIcXHdGx5i4INgaDNPnrnUVGh8vinDkq7lRurHj+rlelR6vL718L3LM0ZQ Rstv4g8fsMlYMJF5IuZinEnEsVIYkYDqdNt1er9ik/cHq76w== X-Google-Smtp-Source: AGHT+IH9w8uBNfqf+p3yh/FJH5Dbcvp/NekQL5E7NiT5DuVK5jNh0zotMULWvDCzMS1XtUQ18xJ55wJzAo6bZuTRIRM= X-Received: by 2002:a05:622a:1a1f:b0:458:2aac:e502 with SMTP id d75a77b69052e-45c9f20abc5mr23166151cf.23.1727402216182; Thu, 26 Sep 2024 18:56:56 -0700 (PDT) MIME-Version: 1.0 From: Aditya Singh Date: Fri, 27 Sep 2024 07:26:45 +0530 Message-ID: Subject: Request for Insights on ID Column Migration Approach To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="0000000000007af83b0623102b95" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007af83b0623102b95 Content-Type: text/plain; charset="UTF-8" I am just contacting you to talk about a current issue with our database. We have run out of a positive sequence in one of our tables and are now operating with negative sequences. To address this, we plan to migrate from the int4 ID column to an int8 ID column. The plan involves renaming the int8 column to the id column and setting it as the primary key. However, this process will require downtime, which may be substantial in a production environment. Fortunately, we have noted that other tables do not use the id column as a foreign key, which may help mitigate some concerns. Our Approach: 1. *Create a Unique Index*: We will first create a unique index on the new ID column before renaming it and altering it to be non-nullable. This step will necessitate scanning the entire table to verify uniqueness. 2. *Add Primary Key*: After ensuring the uniqueness, we will add the ID column as the primary key. By doing this, we hope to bypass the additional scanning for uniqueness and nullability, as the column will already be set as not nullable and will have the uniqueness constraint from the unique index. We want to confirm if this approach will work as expected. If we should be aware of any potential pitfalls or considerations, could you please provide insights or point us toward relevant documentation? Thank you so much for your help, and I look forward to your guidance. Best regards, Aditya Narayan Singh Loyalty Juggernaut Inc. -- *Confidentiality Warning:* This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or other use of this message and any attachments is strictly prohibited. If received in error, please notify the sender immediately and permanently delete it. --0000000000007af83b0623102b95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am just contacting you to talk about a current issue = with our database. We have run out of a positive sequence in one of our tab= les and are now operating with negative sequences. To address this, we plan= to migrate from the=C2=A0int4=C2=A0ID column to an=C2=A0int8=C2=A0ID column.

The plan involves renaming the=C2=A0int8=C2=A0column to the=C2=A0id=C2=A0column and setti= ng it as the primary key. However, this process will require downtime, whic= h may be substantial in a production environment. Fortunately, we have note= d that other tables do not use the=C2=A0id=C2=A0column as a fo= reign key, which may help mitigate some concerns.

Our Approach:

=
  1. Create a Unique Index: We will first create a unique index on the new ID column before renaming= it and altering it to be non-nullable. This step will necessitate scanning= the entire table to verify uniqueness.

  2. Add Primary Key: After ensuring the uniqueness, we = will add the ID column as the primary key. By doing this, we hope to bypass= the additional scanning for uniqueness and nullability, as the column will= already be set as not nullable and will have the uniqueness constraint fro= m the unique index.

We want to confirm if this approach wil= l work as expected. If we should be aware of any potential pitfalls or cons= iderations, could you please provide insights or point us toward relevant d= ocumentation?

Thank you so much for your help, and I look forward to = your guidance.

Best regards,

Aditya Narayan Singh
Loyalty Ju= ggernaut Inc.



C= onfidentiality Warning:
Th= is message and any attachments are intended only for the use of the intende= d recipient(s), are confidential, and may be privileged. If you are not the= intended recipient, you are hereby notified that any disclosure, copying, = distribution, or other use of this message and any attachments is strictly = prohibited. If received in error, please notify the sender immediately and = permanently delete it.

--0000000000007af83b0623102b95--