| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: do only critical work during single-user vacuum? |
| Date: | 2022-02-17 03:07:50 |
| Message-ID: | CAH2-Wz=oupgSJdRXNmcx3nDyrSQrWtZDw0ZtOibXP0g20_1x+w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 16, 2022 at 6:56 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think that's not really what is happening, at least not in the cases
> that typically are brought to my attention. In those cases, the
> typical pattern is:
> 5. None of the tables in the database have been vacuumed in a long
> time. There are a million XIDs left. How many of the tables in the
> database are going to be truncate when they are vacuumed and burn one
> of the remaining XIDs? Anybody's guess, could be all or none.
I have to admit that this sounds way more plausible than my
speculative scenario. I haven't been involved in any kind of support
case with a customer in a *long* time, though (not by choice, mind
you).
> 6. Sometimes the user decides to run VACUUM FULL instead of plain
> VACUUM because it sounds better.
It's a pity that the name suggests otherwise. If only we'd named it
something that suggests "option of last resort". Oh well.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-02-17 03:08:43 | Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM |
| Previous Message | Robert Haas | 2022-02-17 02:56:26 | Re: do only critical work during single-user vacuum? |