Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nC2F4-0000ot-Jl for pgsql-admin@arkaria.postgresql.org; Mon, 24 Jan 2022 16:30:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nC2F3-00080E-7s for pgsql-admin@arkaria.postgresql.org; Mon, 24 Jan 2022 16:30:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nC2F2-000805-Nw for pgsql-admin@lists.postgresql.org; Mon, 24 Jan 2022 16:30:52 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nC2Ev-0001HN-IE for pgsql-admin@lists.postgresql.org; Mon, 24 Jan 2022 16:30:51 +0000 Received: by mail-wm1-x330.google.com with SMTP id l12-20020a7bc34c000000b003467c58cbdfso34615094wmj.2 for ; Mon, 24 Jan 2022 08:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=e3oLXXSlXfpL7aNrp1atuU7W6obByotGNZ7kFbT2Y9c=; b=3F+B1FSiEU3qcdQHO/ajMIidIN7qv4qE5X2L1ZeS1yHNK3tGoFZ3YSBhCx39SYY+yQ syWB8f2s6btdxKV442Kb1KOjBD8Dis2tEj5jp1lrC0IcVhX0w4NsXi2TBWwCdnp3kFuM ql3EIwPKiolkCdbQ92Rb3/t9HBAoZo4s+2/2aL3wAWkrcwId2YxEDgq2VLVu87l47h2f iiSfv+SM7KKiYKgitFY+5KNkfbyrd5QI04sVdZf9sdtHPL17usX5BXmnUaP+LtYqjlKB XNdVr3GkLiUq5uNQ549RXfVwfyuA5DAeH7RziE4ZwH2XjvZtAEczpamQxsyL08aKzlZV MYsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=e3oLXXSlXfpL7aNrp1atuU7W6obByotGNZ7kFbT2Y9c=; b=yGC/Ss5RDtTXModrHuxts3fzYepCVxt/9wq4NuKsodDI9Hbwa1hXye5p9QmKZXRAXH D7zpgVwEygBuleA6jxoOKTpGsBncDlXZmsQwDz4i0OnZC9BgdcWsXQ5Q+ZZSBLI9DWWG SIBUtoPVYZtwnO2torwoyy+n3fe36tBuKurVp13w4oj8pANJ1aDMIwTiRiM8Ib8aDsgz 4FQ4yXFuDBKAtWuzSrNbMMIlRpJhG6sosHVsK2xPGgpe8kFWRD2qKWJHFhuYPu23WrDu agtaID0LOUyta/kFPU2frnTSM+bLJyzeb6h0ZepbOF3hZUlUlUOMjtOxh50/kBysf+JN Iijw== X-Gm-Message-State: AOAM532kY7lPrHVDjxjh008p3xJiyUs/d9OUViFWSPyaLM1n8igIfCgX FRyKJmznL/qck1MeEItMs3C8uQ== X-Google-Smtp-Source: ABdhPJz3c/SFkhITQRHOyoEs/NkGm16IlLXtqXhymgA9bI8afbVYRSp3IvrYrKGvuhJJiGS8YgiGfw== X-Received: by 2002:a05:600c:1c94:: with SMTP id k20mr2497891wms.169.1643041843287; Mon, 24 Jan 2022 08:30:43 -0800 (PST) Received: from localhost.localdomain (dynamic-ea4d6itoftwgrmduu-pd01.res.v6.highway.a1.net. [2001:871:5e:430:45b2:f73c:6cfc:6aa6]) by smtp.gmail.com with ESMTPSA id m6sm3490607wrw.54.2022.01.24.08.30.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 08:30:42 -0800 (PST) Message-ID: <599f850b109d98148ee512890ebe6ec4bfbfe26b.camel@cybertec.at> Subject: Re: Determine potential change in table size after a column dropped? From: Laurenz Albe To: Wells Oliver Cc: Ron , pgsql-admin@lists.postgresql.org Date: Mon, 24 Jan 2022 17:30:42 +0100 In-Reply-To: References: <84b61f419a0a5ba1049c7d74a85b6790bfe9e1e9.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2022-01-24 at 08:08 -0800, Wells Oliver wrote: > > > I need only drop the column and VACUUM FULL the table, and not the entire DB, right? > > > > Not that VACUUM (FULL) will *not* physically get rid of a dropped column, > > as it just copies the complete rows to a new table. > > > > You would need something like: > > > > CREATE TABLE newtab (LIKE oldtab); > > INSERT INTO newtab SELECT * FROM oldtab; > > So, there's really no way to reclaim space from a dropped column other than > entirely creating a new table? Correct, as far as I know. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com