| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: do only critical work during single-user vacuum? |
| Date: | 2022-01-19 19:14:13 |
| Message-ID: | CAFBsxsF2A6jwC5XZ5+Hw9U+6Oh4gSM+w3oU3p4g6T0CpFYd7ag@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 19, 2022 at 12:46 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Jan 14, 2022 at 7:04 AM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> >
> > I guess I'm ultimately imagining the new options as replacing the
> > vacuumdb implementation. IOW vacuumdb would just use MIN_(M)XID_AGE
> > behind the scenes (as would a new top-level command).
>
> I had the same idea.
This seems to be the motivating reason for wanting new configurability
on the server side. In any case, new knobs are out of scope for this
thread. If the use case is compelling enough, may I suggest starting a
new thread?
Regarding the thread subject, I've been playing with the grammar, and
found it's quite easy to have
VACUUM FOR WRAPAROUND
or
VACUUM FOR EMERGENCY
since FOR is a reserved word (and following that can be an IDENT plus
a strcmp check) and cannot conflict with table names. This sounds a
bit more natural than VACUUM LIMIT. Opinions?
--
John Naylor
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2022-01-19 19:24:31 | Re: speed up text_position() for utf-8 |
| Previous Message | Andres Freund | 2022-01-19 19:07:35 | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |