"Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> And, as far as I can see from a quick review of the thread,
>> we don't really have consensus on the names and behaviors.
> Consensus on the name seems to use truncate rather than shrink (a few poople
> kindly said they like shrink, and I'm OK with either name.) And there's no
> dispute on the behavior. Do you see any other point?
The last patch uses the name vacuum_truncate_enabled, which so far
as I can see never appeared in the thread before today. How can
you claim there's consensus for that?
I see references back in February to truncate_enabled and vacuum_enabled,
but there was certainly no consensus for either, seeing how long the
thread has dragged on since then (those references are barely halfway
down the thread). Pasting them together to make a carpal-tunnel-inducing
name isn't automatically going to satisfy people.
Also, it looks like one of the main bones of contention is whether
the option is named consistently with the index-scan-disable option,
which seems to have ended up named "vacuum_index_cleanup". I submit
that "vacuum_truncate_enabled" is not consistent with that; it's not
even the same part of speech.
The closest match to that name, probably, is just "vacuum_truncate" ---
which was proposed at the beginning of March, but apparently also
rejected, because there's no subsequent reference.
My own dog in this fight is that we shouldn't have the option at all,
never mind what the name is. A persistent reloption to disable truncation
seems like a real foot-gun. I'd be okay with a VACUUM command option,
but for some reason that isn't there at all.
regards, tom lane
