On 15 May 2012 15:17, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, May 14, 2012 at 10:24 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> On 14 May 2012 15:09, Robert Haas <robertmhaas@gmail.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.
We don't have enough evidence to show that there are any gains to be
had here in a real world situation.
Few if any benchmarks show anything of value, and if they do it is
because they are too-regular and not very real.
My comments were appropriate: if I tried to suggest we add
commit_delay as a feature, it would be rejected and rightly so. Some
caution in its removal is appropriate, but since we've been discussing
it since before your first post to hackers, probably even before mine,
I figure that is way past long enough.
I beg you to prove me wrong and demonstrate the value of commit_delay,
since we will all benefit from that.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services