Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

On Thu, Jun 28, 2012 at 1:32 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> Anyway, it seems that no one other than you and I is very excited
>> about renaming this for whatever reason, so maybe we should leave it
>> at that.
>
> I think not changing the name is a really bad decision, and I am
> personally unhappy about it. I immediately agreed to your proposed
> adjustment to the patch without really thinking that it mattered,
> because it had no plausible downside, so why not?
>
> That's all I have to say about the matter. If it isn't obvious that
> the name should be changed, based on what I've already said, it never
> will be.

All in all, I don't think this can be a very productive discussion
unless someone just pitches a equal or better name overall in terms of
conciseness and descriptiveness.  I'd rather optimize for those
attributes.  Old advice is old; that's the nature of the beast.

The one benefit I can think of for name shuffling is avoiding
accidental negation of the optimization when porting Postgres
configuration from older clusters, and even then I don't think the
rename-on-change strategy is a scalable one; a tuning-linting
tool is probably the only scalable option if one is concerned about
making sure that those forward-porting their configurations or
managing multiple postgres versions don't shoot themselves in the
foot.

-- 
fdr