Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date
Msg-id CAEYLb_VBb3fxMhgZikS9piHR540vsEckhdToq4+A5zhnuxNUug@mail.gmail.com
Whole thread Raw
In response to Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
List pgsql-hackers
On 28 June 2012 20:55, Robert Haas <robertmhaas@gmail.com> wrote:
>>> I don't buy this line of reasoning at all.  If we're going to rename
>>> the GUC, it should be for accuracy, not PR value.  If we start
>>> renaming something every time we improve it, we're going to go nuts.
>>> We improved lots of things in 9.2; they didn't all get renamed.
>>
>> That is a false equivalence, and you know it.
>
> A false equivalence between what and what?

Changing the name in order to create some buzz about it, or to
highlight an improvement, is quite different to changing the name
because the practical advice surrounding the setting has suddenly
altered, almost diametrically, and after a very long period.

>> Who said anything about PR value? I'm concerned with not confusing users.
>
> My point here is that we don't normally rename things because they
> work better than they used to.  Whether that is called PR value or not
> confusing users, we don't normally do it.

That makes sense. I don't dispute that. We aren't talking about an
incremental improvement here, are we? We're talking about night and
day. That is probably an unprecedented state of affairs, so I don't
see any reason to invoke precedent.

The reason the VACUUM FULL situation isn't at all comparable here is because:

For VACUUM FULL:

User googles "VACUUM FULL", gets something from the 8.* docs, or
something from that era. (This happens more often than not for any
given Postgres term, as you rightly complained about at PgCon).

They see something that says "you should probably use cluster
instead". They do so, and are no worse off for it.

For commit_delay:

User googles commit_delay, and sees something from that same period
that says "you don't want to use this". They naturally assume that
they don't. They lose whatever benefit they might have had from the
new implementation.

> We sometimes rename things because they do something *different* than
> what they used to do.  But not just because they work better.

It does do something different. That's why you proposed changing the name.

> 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.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: embedded list v2
Next
From: Andres Freund
Date:
Subject: Re: embedded list v2