From: | Wing Kin Chong <Wing(dot)Chong(at)mii(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: using TEMP with the VACUUM function |
Date: | 2024-07-01 23:25:31 |
Message-ID: | CO1P222MB035434BFA0BA3B9B881005878CD32@CO1P222MB0354.NAMP222.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi David and Tom,
Thanks for your assistance,
Yes, it's the vacuum full command on a Table,
which some client's databases are over 100 GB,
after the client deleted the info,
the database size is not Reduced until we run the vacuum full command,
Is there any way to find out the disk space we need to run the vacuum full command on the database (or a table)?
Regards
Wing CHONG
Senior Developer | Buildsoft
p: 02 4626 4909 | w: buildsoft.com.au<http://www.buildsoft.com.au/>
[Connect with us via LinkedIn]
[Check out our instructional videos on Youtube]
[Connect with us on Facebook]
________________________________
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Tuesday, July 2, 2024 12:32 AM
To: David G. 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
"David G. Johnston" <david. g. johnston@ gmail. com> writes: > On Sunday, June 30, 2024, Wing Kin Chong <Wing. Chong@ mii. com> wrote: >> Allow the VACUUM function using the system Environment Variables "TEMP" or >> "TMP"
"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
MiTek Inc. and its subsidiaries are a global operating company that serves its residential and commercial customers in North America, Europe, Middle East, Africa, and Asia Pacific. Additional information about our corporate organization is available at www.mii.com/corporate-structure/. MiTek Holdings, Inc.. All Rights Reserved ---- This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it. If the disclaimer can't be applied, take no action.
From | Date | Subject | |
---|---|---|---|
Next Message | Waka Ranai | 2024-07-02 09:57:28 | Re: Bug report - pg_upgrade tool seems to have a race condition when trying to delete a pg_wal file |
Previous Message | Erik Wienhold | 2024-07-01 17:30:12 | Re: BUG #18527: Imported data using a csv file and made a latest entry into same table using a form. Got an issue! |