On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki <tsunakawa.ta...@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
