Re: Why do we still have commit_delay and commit_siblings?

On Mon, May 14, 2012 at 10:24 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 14 May 2012 15:09, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I don't have a strong opinion
>> about that, and welcome discussion.  But I'm always going to be
>> opposed to adding or removing things on the basis of what we didn't
>> test.
>
> The subject of the thread is "Why do we still have commit_delay and
> commit_siblings?". I don't believe that anyone asserted that we should
> remove the settings without some amount of due-diligence testing.
> Simon said that thorough testing on many types of hardware was not
> practical, which, considering that commit_delay is probably hardly
> ever (never?) used in production, I'd have to agree with. With all due
> respect, for someone that doesn't have a strong opinion on the
> efficacy of commit_delay in 9.2, you seemed to have a strong opinion
> on the standard that would have to be met in order to deprecate it.
>
> I think we all could stand to give each other the benefit of the doubt more.

I am a bit perplexed by this thread. It appeared to me that you were
saying that these settings could not ever possibly be useful and
therefore we ought to remove them right now, and I said we should
gather some data first, because the current behavior, without using
these settings, appears to be about 50% of the optimum. If you agree
we need to gather some data first, then apparently we don't disagree
about anything, but that wasn't mentioned in your original email or in
Simon's reply to my post. There are certainly many instances where
we've made changes quickly without gathering much data first, so I
feel that it wasn't ridiculous on my part to think that might be the
proposal on the table.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company