From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Wing Kin Chong <Wing(dot)Chong(at)mii(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: using TEMP with the VACUUM function |
Date: | 2024-07-01 14:32:42 |
Message-ID: | 2738306.1719844362@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Sunday, June 30, 2024, Wing Kin Chong <Wing(dot)Chong(at)mii(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2024-07-01 15:08:29 | BUG #18527: Imported data using a csv file and made a latest entry into same table using a form. Got an issue! |
Previous Message | David G. Johnston | 2024-07-01 13:13:49 | Re: using TEMP with the VACUUM function |