From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New vacuum option to do only freezing |
Date: | 2019-04-01 05:26:15 |
Message-ID: | CAD21AoCKKwvgQgWxKwPPmVFJjQVj6c=oV9dtdiRthdV+WjnD4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 30, 2019 at 5:04 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Mar 29, 2019 at 12:27 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > Yeah, but since multiple relations might be specified in VACUUM
> > command we need to process index_cleanup option after opened each
> > relations. Maybe we need to process all options except for
> > INDEX_CLEANUP in ExecVacuum() and pass VacuumStmt down to vacuum_rel()
> > and process it in manner of you suggested after opened the relation.
> > Is that right?
>
> Blech, no, let's not do that. We'd better use some method that can
> indicate yes/no/default. Something like psql's trivalue thingy, but
> probably not exactly that. We can define an enum for this purpose,
> for example - VACUUM_INDEX_CLEANUP_{ENABLED,DISABLED,DEFAULT}. Or
> maybe there's some other way. But let's not pass bits of the parse
> tree around any more than really required.
I've defined an enum VacOptTernaryValue representing
enabled/disabled/default and added index_cleanup variable as the new
enum type to VacuumParams. The vacuum options that uses the reloption
value as the default value such as index cleanup and new truncation
option can use this enum and set either enabled or disabled after
opened the relation when it’s set to default. Please find the attached
patches.
>
> > > I think it would be better to just ignore the INDEX_CLEANUP option
> > > when FULL is specified.
> >
> > Okay, but why do we ignore that in this case while we complain in the
> > case of FULL and DISABLE_PAGE_SKIPPING?
>
> Well, that's a fair point, I guess. If we go that that route, we'll
> need to make sure that setting the reloption doesn't prevent VACUUM
> FULL from working -- the complaint must only affect an explicit option
> on the VACUUM command line. I think we should have a regression test
> for that.
I've added regression tests. Since we check it before setting
index_cleanup based on reloptions we doesn't prevent VAUCUM FULL from
working even when the vacuum_index_cleanup is false.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
v12-0001-Add-INDEX_CLEANUP-option-to-VACUUM-command.patch | application/x-patch | 21.3 KB |
v12-0002-Add-disable-index-cleanup-option-to-vacuumdb.patch | application/x-patch | 5.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-04-01 06:10:41 | Re: Progress reporting for pg_verify_checksums |
Previous Message | Amit Langote | 2019-04-01 04:55:50 | Re: speeding up planning with partitions |