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 1sOI5K-00DUfY-R7 for pgsql-bugs@arkaria.postgresql.org; Mon, 01 Jul 2024 14:32:50 +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 1sOI5J-002Tu9-7g for pgsql-bugs@arkaria.postgresql.org; Mon, 01 Jul 2024 14:32:49 +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 1sOI5I-002Tu1-VE for pgsql-bugs@lists.postgresql.org; Mon, 01 Jul 2024 14:32:49 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOI5G-004V3r-Tg for pgsql-bugs@postgresql.org; Mon, 01 Jul 2024 14:32:48 +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 461EWgxx2738307; Mon, 1 Jul 2024 10:32:42 -0400 From: Tom Lane To: "David G. Johnston" cc: Wing Kin Chong , "pgsql-bugs@postgresql.org" Subject: Re: using TEMP with the VACUUM function In-reply-to: References: Comments: In-reply-to "David G. Johnston" message dated "Mon, 01 Jul 2024 06:13:49 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2738305.1719844362.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Mon, 01 Jul 2024 10:32:42 -0400 Message-ID: <2738306.1719844362@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Sunday, June 30, 2024, Wing Kin Chong wrote: >> Allow the VACUUM function using the system Environment Variables "TEMP" or >> "TMP" please. > The vacuum full command is what you are describing, right? > Not going to happen - the added space is not for temporary data, it’s for > the real new table being built. We’d have to move the data at the end of > the command if it was anywhere besides the data directory. Also, this would do exactly nothing to reduce the peak disk space usage. The fundamental problem for VACUUM FULL is that it can't safely unlink the old table/index files until the new ones are fully built and fsync'd. Having a temporary copy somewhere else doesn't alleviate that. (In fact, if the "somewhere else" isn't on a physically different file system, the third copy would make things very much worse.) regards, tom lane