From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | david(dot)g(dot)johnston(at)gmail(dot)com |
Cc: | sawada(dot)mshk(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com |
Subject: | Re: show "aggressive" or not in autovacuum logs |
Date: | 2017-09-05 08:14:33 |
Message-ID: | 20170905.171433.226648412.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
At Mon, 28 Aug 2017 20:07:32 -0700, "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> wrote in <CAKFQuwY4GBEzjwJwQRUDRD-1ZvUFXPTQOiiH4UrP1jn1sMGp1w(at)mail(dot)gmail(dot)com>
> On Mon, Aug 28, 2017 at 2:26 AM, Kyotaro HORIGUCHI <
> horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> > https://www.postgresql.org/docs/devel/static/runtime-config-client.html
> >
> > > VACUUM performs an aggressive scan
> >
>
> Maybe this should gets its own thread/patch but I'll tack this on here
> since it all seems related.
>
> That paragraph you linked has a couple of typos:
>
> "Although users can set this value anywhere from zero to two billions,
> VACUUM" ...
>
> should be 'two billion' (i.e., drop the "s")
Sure. (and I would make the same mistake..)
> "...so that a periodical manual VACUUM has..."
>
> 'periodic' - though the description in the linked 24.1.5 is somewhat
> clearer (and longer) - the gap exists for the benefit of routine vacuum
> invocations to detect the need for an aggressive vacuum as part of a normal
> operating cycle rather than the last routine vacuum being non-aggressive
> and shortly thereafter an auto-vacuum anti-wraparound run is performed.
>
> Current:
>
> VACUUM will silently limit the effective value to 95% of
> autovacuum_freeze_max_age, so that a periodical manual VACUUM has a chance
> to run before an anti-wraparound autovacuum is launched for the table.
>
> My interpretation:
>
> VACUUM will silently limit the effective value to 95% of
> autovacuum_freeze_max_age so that a normal scan has a window within which
> to detect the need to convert itself to an aggressive scan and preempt the
> need for an untimely autovacuum initiated anti-wraparound scan.
I haven't find the phrase "normal scan" in the documentation.
Instaed, it seems to me that it should be "normal VACUUMs" as
seen in 24.1.5, which is VACUUM command without FREEZE
option. ("normal index scan" is another thing.)
So more verbosely, the interpretation would be the following
| VACUUM will silently limit the effective value to 95% of
| autovacuum_freeze_max_age so that a periodic (manual) VACUUM
| without FREEZE option has a window within which to detect the
| need to convert itself to an aggressive VACUUM and preempt the
| need for an untimely autovacuum initiated anti-wraparound scan.
> As noted in the 24.1.5 that "normal scan" can be time scheduled or an
> update driven auto-vacuum one. It could be manual (though not really
> periodic) if one is monitoring the aging and is notified to run on manually
> when the age falls within the gap.
>
> "Aggressive" sounds right throughout all of this.
>
> Up-thread:
> INFO: vacuuming "public.it" in aggressive mode
>
> Maybe:
> INFO: aggressively vacuuming "public.it"
> INFO: vacuuming "public.it"
Hmm. I believed that the 'vacuuming' is a noun and the phrase
seen in my patch just submitted is 'aggressive vacuuming'. But of
course it's highly probable that I'm wrong.
> Likewise:
> LOG: automatic vacuum of table "postgres.public.pgbench_branches": mode:
> aggressive, index scans: 0
>
> could be:
> LOG: automatic aggressive vacuum of table
> "postgres.public.pgbench_branches", index scans: 0
Yeah, this is just the same with mine.
> Having read the docs and come to understand what "aggressive" means two
> wordings work for me (i.e., leaving non-aggressive unadorned).
> David J.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-09-05 08:22:01 | Re: multiple target of VACUUM command |
Previous Message | Konstantin Knizhnik | 2017-09-05 08:10:38 | Re: Secondary index access optimizations |