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?  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Why do we still have commit_delay and commit_siblings?
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: Analyzing foreign tables & memory problems