On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance." I've looked up the meaning in the
dictionary. Nuisance is like a trouble maker...
Yes, and "attractive nuisance" means something that, superficially, it
looks like a good idea, but later, you find out that it creates many
problems.
I want to make one other point about this patch, which is that over on
the thread "New vacuum option to do only freezing" we have a patch
that does a closely-related thing. Both patches skip one phase of the
overall VACUUM process. THIS patch wants to skip truncation; THAT
patch wants to skip index cleanup. Over there, we seem to have
settled on DISABLE_INDEX_CLEANUP -- only available as a VACUUM option
-- and here I think the proposal is currently VACUUM_SHRINK_ENABLED --
only available as a reloption.
Now that seems not very consistent. One can only be set as a
reloption, the other only as a VACUUM option. One talks about what is
enabled, the other about what is disabled. One puts enable/disable at
the start of the name, the other at the end.
My proposal would be that we make both options available as both
reloptions and vacuum options. Call the VACUUM options INDEX_CLEANUP
and TRUNCATE and the default will be true but the user can specify
false. For the reloptions, prefix "vacuum_", thus
vacuum_index_cleanup = true/false and vacuum_truncate = true/false.
If that doesn't appeal, I am open to other ideas how to make this
consistent, but I think it should in some way be made consistent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
