| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Murthy Nunna <mnunna(at)fnal(dot)gov>, "depesz(at)depesz(dot)com" <depesz(at)depesz(dot)com> |
| Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: Vacuumdb on a table |
| Date: | 2023-10-19 20:04:35 |
| Message-ID: | b8c94042591dc999ab7a183606664a19b7abfa96.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Thu, 2023-10-19 at 17:08 +0000, Murthy Nunna wrote:
> I retried with -F. That actually worked and lowered the relfrozenxid of the table.
>
> 1) I am wondering if -F option interferes with application (table lock, row lock etc).
No, it only does more work and wil use more resources.
> 2) It says "aggressively vacuuming "<table>". Do you always see this with -F option?
> Is it harmless in terms of locking select/insert/update/delete statements from application?
"Aggressive" is not as nasty as it sounds. It just means that it won't skip pages that are
all-visible or pinned by other backends.
My guess is that
vacuumdb --disable-page-skipping --no-index-cleanup -d <database> -t <table>
would have worked as well, and it would have been cheaper.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Evan Rempel | 2023-10-19 20:21:23 | Re: Binaries for EOL version? |
| Previous Message | Ron | 2023-10-19 20:02:45 | Re: Binaries for EOL version? |