Re: Why do we still have commit_delay and commit_siblings?
От | Magnus Hagander |
---|---|
Тема | Re: Why do we still have commit_delay and commit_siblings? |
Дата | |
Msg-id | CABUevEyL+--4GZDG4PxewPuDyjZ4uMFqqxXNLukYf=3qRJsT+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why do we still have commit_delay and commit_siblings? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Why do we still have commit_delay and commit_siblings?
|
Список | pgsql-hackers |
On Mon, May 14, 2012 at 8:17 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, May 14, 2012 at 2:07 AM, Simon Riggs <simon@2ndquadrant.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. >> We don't ADD parameters based on supposition, why should we avoid >> removing parameters that have no measured benefit? > > If they have no actual benefit, of course we should remove them. If > they have no measured benefit because no one has bothered to measure, > that's not a reason to remove them. Another option might be to as a first step remove them from the .conf file or have a "deprecated" section, maybe? But if we do that, people aren't likely to use them anyway... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: