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 1sRkU4-000oXH-Eb for pgsql-general@arkaria.postgresql.org; Thu, 11 Jul 2024 03:28:40 +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 1sRkU1-00AdmG-3X for pgsql-general@arkaria.postgresql.org; Thu, 11 Jul 2024 03:28:37 +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 1sRkU0-00Adm7-N3 for pgsql-general@lists.postgresql.org; Thu, 11 Jul 2024 03:28:36 +0000 Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sRkTx-001UXI-E4 for pgsql-general@lists.postgresql.org; Thu, 11 Jul 2024 03:28:36 +0000 Received: by mail-vs1-xe30.google.com with SMTP id ada2fe7eead31-48fefaf11f9so128946137.1 for ; Wed, 10 Jul 2024 20:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720668511; x=1721273311; 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=3YTgP9fT94S5k8cX19BRIiRwDVE5nOcduj6t0bcEk9U=; b=DS0GDZA/Jq3mgQG6TbZIF7SHVAf9MP3DNfUt64KV4bL7OO5DZKoKZIlYDTWAzD0gXs YTX8g57+5cAGbqhy8zuEi0oHhMJdbM7PwGkbd2XNPpQIWKfGDqkYWlHZbocayGVKJXp0 OUiCyxwH3YJ+vnf7KLDgDJEqZaeqe68Zikoqc5B3PUBXnqMmVIFOpP0jcyFOOe2kaaiZ DQsoY+YmV7hgOrlNxPfHlsQZFBpOaHHujKAs/qzpotOfUin+xA4lZ6fGlEiWc2iWydjM rrFTyC9HbBhX0f/7uxQO/Oe4VmVWqvV0Ob5NcCp7KigqbQjENpgHm4WFcyB0/uFfXVrR U9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720668511; x=1721273311; 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=3YTgP9fT94S5k8cX19BRIiRwDVE5nOcduj6t0bcEk9U=; b=oCjeCEwzw1z80kT3Z4Aa6noFQgp75YZZp6xD/jQAP15wa5Lu6JTmiFGlkkgfu48IG1 5vTrR1qctTVWr6qKlvubCO/Aj9hWPViqAYOUQl6JBbR0aMab/4ao3bLKKZeQp7wjY9lc kOC1nHojJdW0yP9MtBpS5K2D7JRIPgdf2rAW+/qidLfj2zglMw57uwhBkhKSqmx6C6BQ /9UriuGdQaxxW3V9HUEeqOgBj0xdUk3O2RTbMUZgjGw+EdScHWve1ba6u/fNVWyE6AYh bv/PGZgZQ1wBgZUoY3cqPyhUwPlG/ZIWS52I/T/nsDZPoTI4E19L8C9E/A8F6lEqscxG N24A== X-Gm-Message-State: AOJu0YxxSMGuNEn++CCqMF3qM8N2sS6O0kf8JXG58asgHTneUP8BILTm 6bwOq3ds8GDj3Zh+zw1my2slPYVkRqoJvXZPsWGsb96eqa8ppMSgRlR0kEqvgK3UPKl79SyUYS9 rvFeKkRonz3ykrP6RA77Hg8cjfp0= X-Google-Smtp-Source: AGHT+IGqG7V4xOBpycHj0nUIwuRFwSIgDOAvLRpThG+zEv5ivBPNEGtyWvny7RCSXnvb6922snI1NihLlFefjihOJBQ= X-Received: by 2002:a05:6102:3e96:b0:491:1046:bc28 with SMTP id ada2fe7eead31-4911046c4c3mr697108137.5.1720668511043; Wed, 10 Jul 2024 20:28:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: sud Date: Thu, 11 Jul 2024 08:58:18 +0530 Message-ID: Subject: Re: Dropping column from big table To: Adrian Klaver Cc: pgsql-general Content-Type: multipart/alternative; boundary="00000000000060888e061cf05bab" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000060888e061cf05bab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2024 at 2:52=E2=80=AFAM Adrian Klaver wrote: > > https://www.postgresql.org/docs/current/sql-altertable.html > > "The DROP COLUMN form does not physically remove the column, but simply > makes it invisible to SQL operations. Subsequent insert and update > operations in the table will store a null value for the column. Thus, > dropping a column is quick but it will not immediately reduce the > on-disk size of your table, as the space occupied by the dropped column > is not reclaimed. The space will be reclaimed over time as existing rows > are updated. > > To force immediate reclamation of space occupied by a dropped column, > you can execute one of the forms of ALTER TABLE that performs a rewrite > of the whole table. This results in reconstructing each row with the > dropped column replaced by a null value. > " > > Thank you so much. When you said *"you can execute one of the forms of ALTER TABLE that performs a rewrite* *of the whole table."* Does it mean that post "alter table drop column" the vacuum is going to run longer as it will try to clean up all the rows and recreate the new rows? But then how can this be avoidable or made better without impacting the system performance and blocking others? --00000000000060888e061cf05bab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jul 11, 2024 at 2:52=E2=80=AFAM A= drian Klaver <adrian.klaver= @aklaver.com> wrote:

https://www.postgresql.org/docs/current/s= ql-altertable.html

"The DROP COLUMN form does not physically remove the column, but simpl= y
makes it invisible to SQL operations. Subsequent insert and update
operations in the table will store a null value for the column. Thus,
dropping a column is quick but it will not immediately reduce the
on-disk size of your table, as the space occupied by the dropped column is not reclaimed. The space will be reclaimed over time as existing rows are updated.

To force immediate reclamation of space occupied by a dropped column,
you can execute one of the forms of ALTER TABLE that performs a rewrite of the whole table. This results in reconstructing each row with the
dropped column replaced by a null value.
"


Thank you so much. When you = said "you can execute one of the forms of ALTER TABLE that performs= a rewrite
of the whole table."=C2=A0Does it mean= that post "alter table drop column" the vacuum is going to run l= onger as it will try to clean up all the rows and recreate the new rows? Bu= t then how can this be avoidable or made better without impacting the syste= m performance and=C2=A0blocking others?
--00000000000060888e061cf05bab--