Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Reviewing freeze map code
Date
Msg-id CAD21AoCpvLJ3XeQ4GkjNX6Zz+pd7M_L6VwGZZfQ5Ctmw3j3Q5g@mail.gmail.com
Whole thread Raw
In response to Re: Reviewing freeze map code  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, May 17, 2016 at 3:32 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Masahiko Sawada wrote:
>> On Mon, May 16, 2016 at 10:49 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> > We should support scan_all only with the new-style options syntax for
>> > VACUUM; that is, vacuum (scan_all) rename.  That doesn't require
>> > making scan_all a keyword, which is good: this is a minor feature, and
>> > we don't want to bloat the parsing tables for it.
>>
>> I agree with having new-style options syntax.
>> Isn't it better to have SCAN_ALL option without parentheses?
>>
>> Syntaxes are;
>> VACUUM SCAN_ALL table_name;
>> VACUUM SCAN_ALL;  -- for all tables on database
>
> No, I agree with Robert that we shouldn't add any more such options to
> avoid keyword proliferation.
>
>  Syntaxes are;
>  VACUUM (SCAN_ALL) table_name;
>  VACUUM (SCAN_ALL);  -- for all tables on database

Okay, I agree with this.

> Is SCAN_ALL really the best we can do here?  The business of having an
> underscore in an option name has no precedent (other than
> CURRENT_DATABASE and the like).

Another way is having tool or function that removes _vm file safely for example.

> How about COMPLETE, TOTAL, or WHOLE?

IMHO, I don't have strong opinion about SCAN_ALL as long as we have
document about that option and option name doesn't confuse users.
But ISTM that COMPLETE, TOTAL might make users mislead normal vacuum
as it doesn't do that completely.

Regards,

--
Masahiko Sawada



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: [COMMITTERS] pgsql: Allocate all page images at once in generic wal interface
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Reviewing freeze map code