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 1sbes0-000XcA-B0 for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 11:30:20 +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 1sbery-006bDg-NQ for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 11:30:18 +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 1sbery-006bDY-CF for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 11:30:18 +0000 Received: from mail-yw1-x1134.google.com ([2607:f8b0:4864:20::1134]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sberw-003cYw-4g for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 11:30:17 +0000 Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-664cfc5cf98so1934477b3.2 for ; Wed, 07 Aug 2024 04:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723030214; x=1723635014; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zguZ6TMQfzKCqeBqTgEj+tAJDKX/TQ1JwB6h2KomjRs=; b=d6wxQvGfxOi/WtAc0PYhEeScG3J3z8leZcLvo4UWE78SPE44iw/sdvTfEPTixuR53o fKdjIHkyrOMjunJYf/Jl/yUb+z9YUVXByWgWeHuZGQxw4wi1jLD4e5soZEYA2m5ngiJd p1mZUBKfSwV71P4Cdp3lLmg/S0BpG9wY8x7l3226A2q6ao/3W20jxynb0wdaRgHfDivk pDpPD0dLrZzgUUklzdp6MX+fVK+I1vUuqQwug11bNy112Wa51OxQpK3K1DrNFiTrwRCn tFUoYr7GX0ZSmL23AJieaYP3JnQcu3PRvdizgCfpW4cXJeMzYcy/goubI3WXJQJRo6mo LG0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723030214; x=1723635014; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zguZ6TMQfzKCqeBqTgEj+tAJDKX/TQ1JwB6h2KomjRs=; b=BDMQFkqwAxW3q982n/OaGKzWk3txfaCXiqEcMP+DO3ZPAffPG/HQyTpJ0Q0vSxAT3b pnNOyz98OtKWIndrIn7qJqB97FxB71aM7ywRoGyFdXAe9aC8XvYPVNRjU3mu6dKuMkT8 u4XzuuH/XMLqZIKg5ahEJ0N44dovdL0VyV1DIGohwNHS8CDbT/wWxa4nzVQFpJt5iYHR 1B0Gjz16y9hO1CjpL5tvYrM5zWbQCQlO5+mP3kzcr4xLEFAHaT519C6DMhWSRj2z5sJR 7zofWtPFUdC/TTqmHcpFvWhkvDRcZ8hik+SzBhrkT8bSPP0tYuCVppQgIbZC29lBeCOI 4bZQ== X-Gm-Message-State: AOJu0YxOIMNi05P3t61E7HDsIdYhag440Zb1cIWMCTeKUD5H26KJZTIn tqsNXqH2VEoAJHv85rqqgsUjkEG7h13S8U39Gr682Zn1QO3hCENFHoKaDc47kr9xXDsPZrI4zbE VWFJQqKg6ZABuo1XfsAACXPFqTWo= X-Google-Smtp-Source: AGHT+IFvyMueldKvqNXUBxNgZ/tDhbT7UeDPZ/2anv7CW+E26bUB/3wT0+W2VxnlWuOsgE9XrvXmkjfsQUwj9Y0UWyw= X-Received: by 2002:a25:8447:0:b0:e0b:5cdd:bd12 with SMTP id 3f1490d57ef6-e0bde40600emr8306863276.3.1723030214084; Wed, 07 Aug 2024 04:30:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lok P Date: Wed, 7 Aug 2024 17:00:02 +0530 Message-ID: Subject: Re: Column type modification in big tables To: sud Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000d912ba061f163b21" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d912ba061f163b21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 7, 2024 at 4:51=E2=80=AFPM sud wrote: > > > Others may correct but i think, If you don't have the FK defined on these > columns you can do below. > > > --Alter table add column which will be very fast within seconds as it wil= l > just add it to the data dictionary. > > ALTER TABLE tab1 ADD COLUMN new_column1 NUMERIC(3), new_column2 > varchar2(3); > > > *-- Back populate the data partition wise and commit, if it's really > needed* > > UPDATE tab1_part1 SET new_column1 =3D CAST(old_column1 AS NUMERIC(3)), > new_column2 =3D CAST(old_column2 AS varchar2(3)) ; > commit; > UPDATE tab1_part2 SET new_column1 =3D CAST(old_column1 AS NUMERIC(3)), > new_column2 =3D CAST(old_column2 AS varchar2(3)) ; > commit; > UPDATE tab1_part3 SET new_column1 =3D CAST(old_column1 AS NUMERIC(3)), > new_column2 =3D CAST(old_column2 AS varchar2(3)) ; > commit; > ..... > > > *--Alter table drop old columns which will be very fast within seconds as > it will just drop it from the data dictionary.* > ALTER TABLE your_table DROP COLUMN old_column1, DROP COLUMN old_column2; > Thank you so much. I understand this will be the fastest possible way to achieve the column modification. But talking about the dropped column which will be sitting in the table and consuming storage space, Is it fine to leave as is or auto vacuum will remove the column values behind the scene and also anyway , once those partitions will be purged they will be by default purged. Is this understanding correct? And also will this have any impact on the partition maintenance which is currently done by pg_partman as because the template table is now different internally(not from outside though). Will it cause conflict because of those dropped columns from the main table? --000000000000d912ba061f163b21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 7, 2024 at 4:51=E2=80=AFP= M sud <suds1434@gmail.com> = wrote:


Others may correct but i think, If you = don't have the FK defined on these columns you can do below.

--Alter table add column which will be very fast within seconds as it will= just add it to the data dictionary.

ALTER TABLE tab1 ADD COLUMN new= _column1 NUMERIC(3),=C2=A0 =C2=A0new_column2 varchar2(3);

=
-- Back populate the data partition wise and commit, if it's= really needed

UPDATE tab1_part1 SET new_column1 =3D CAST(old_co= lumn1 AS NUMERIC(3)), new_column2 =3D CAST(old_column2 AS varchar2(3)) ;commit;
UPDATE tab1_part2 SET new_column1 =3D CAST(old_column1 AS NUMER= IC(3)), new_column2 =3D CAST(old_column2 AS varchar2(3)) ;
commit;
UP= DATE tab1_part3 SET new_column1 =3D CAST(old_column1 AS NUMERIC(3)), new_co= lumn2 =3D CAST(old_column2 AS varchar2(3)) ;
commit;
.....

= --Alter table drop old columns which will be very fast within seconds as it= will just drop it from the data dictionary.

ALTER TABLE your_ta= ble DROP COLUMN old_column1, DROP COLUMN old_column2;=C2=A0



Thank you so much.

I und= erstand this will be the fastest possible way to achieve the column modific= ation.

But talking about the dropped column which will be sitt= ing in the table and consuming=C2=A0storage space, Is it fine to leave as i= s or auto vacuum will remove the column values behind the scene and also an= yway , once those partitions will be purged they will be by default purged.= Is this understanding correct?

=C2=A0And also wil= l this have any impact on the partition=C2=A0maintenance which is currently= done by pg_partman as because the template table is now different internal= ly(not from outside though). Will it cause conflict because=C2=A0of those d= ropped columns from the main table?
--000000000000d912ba061f163b21--