Re: Why do we still have commit_delay and commit_siblings?

On Mon, May 14, 2012 at 3:15 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, May 14, 2012 at 8:17 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, May 14, 2012 at 2:07 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> Keeping a parameter without any clue as to whether it has benefit is
>>> just wasting people's time.
>>
>> No, arguing that we should remove a parameter because it's useless
>> when you haven't bothered to test whether or not it actually is
>> useless is wasting people's time.
>
> It's most certainly not, IMHO. Discussing it here is *not* a waste of
> time. Or if any, it's a waste of time for a couple of people. If we
> leave it in, and it's useless, we waste the time of thousands of
> users. The choice between those two should be obvious.

Discussing it in general is not a waste of time, but the argument that
we should remove it because there's no evidence we should keep it is
completely backwards. We should add OR remove things based on
evidence, not the absence of evidence. There is certainly room for
discussion about what amount of evidence is adequate, but I do not
think zero is the right number.

Now, interestingly, Jeff Janes just did some testing, and it shows
almost a 2x speedup. I think that's a much better starting point for
a productive discussion. Does that change your mind at all? Is it
too small a boost to be relevant? Too artificial in some other way?
It doesn't seem impossible to me that the recent group commit changes
made it *easier* to get a benefit out of these settings than it was
before. It may be that with the old implementation, it was hopeless
to get any kind of improvement out of these settings, but it no longer
is. Or maybe they're still hopeless. 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.

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