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 1qs2pU-006bob-1V for pgsql-bugs@arkaria.postgresql.org; Sun, 15 Oct 2023 15:14:55 +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 1qs2pQ-00BRw9-LN for pgsql-bugs@arkaria.postgresql.org; Sun, 15 Oct 2023 15:14:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qs2pQ-00BRw1-As for pgsql-bugs@lists.postgresql.org; Sun, 15 Oct 2023 15:14:53 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qs2pK-000bv1-4b for pgsql-bugs@lists.postgresql.org; Sun, 15 Oct 2023 15:14:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39FFEjc72082193; Sun, 15 Oct 2023 11:14:45 -0400 From: Tom Lane To: Erki Eessaar cc: "pgsql-bugs@lists.postgresql.org" Subject: Re: System administration functions about relation size ignore changes in the table structure In-reply-to: References: <1766109.1697302921@sss.pgh.pa.us> Comments: In-reply-to Erki Eessaar message dated "Sun, 15 Oct 2023 08:27:05 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2082191.1697382885.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Oct 2023 11:14:45 -0400 Message-ID: <2082192.1697382885@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Erki Eessaar writes: > After that I dropped ALL the columns of the table (by the way it is a ni= ce feature that PostgreSQL allows tables without columns). VACUUM ANALYZE = did not change the relation size. VACUUM FULL reduced the size, but it was= still pretty large. You still have 15000 live rows. None of their columns are accessible, but the data is still there physically. Plain VACUUM is not charged with rewriting row contents, only with deleting dead rows, and there are none to delete. IIRC, VACUUM FULL will rewrite the rows to have just null entries, making them smaller (but not zero size). > After that I tried to add a mandatory (NOT NULL) column to the table (wi= th a new name). It failed!! That would work only if you provided a non-null default to populate the column with. > After that I tried to add an optional (permit NULLs) column to the table= . It succeeded but the table now had 15_000 rows with NULLs. As expected. Reducing a row to zero columns does not eliminate the row. > Is it possible somehow to reorganize pages so that the pages that were o= nce used by the relation would be released? VACUUM FULL/CLUSTER will do that, as will variants of ALTER TABLE that force a table rewrite. (As you've found, we've expended a fair amount of effort on avoiding that when possible.) > The border case with evolving the table structure produces a result that= from the point of view of database user is a bug. You seem far too willing to use that word. We have generally optimized these sorts of operations to run quickly, not to reclaim disk space as soon as possible. In the project's opinion, every one of these behaviors is a feature not a bug --- and in many cases, a feature we put considerable sweat into. regards, tom lane