Re: Auto-tuning work_mem and maintenance_work_mem

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Auto-tuning work_mem and maintenance_work_mem
Дата
Msg-id CABUevEz1fqRnncrYLtF8-U3wSrJo4tJCZsr6D+06W1r2W0JgiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Auto-tuning work_mem and maintenance_work_mem  ("MauMau" <maumau307@gmail.com>)
Ответы Re: Auto-tuning work_mem and maintenance_work_mem  ("MauMau" <maumau307@gmail.com>)
Список pgsql-hackers
On Tue, Oct 15, 2013 at 2:47 PM, MauMau <maumau307@gmail.com> wrote:
> From: "Dimitri Fontaine" <dimitri@2ndQuadrant.fr>
>
>> The reason why that parameter default has changed from 5 to 0 is that
>> some people would mistakenly use a prepared transaction without a
>> transaction manager. Few only people are actually using a transaction
>> manager that it's better to have them have to set PostgreSQL.
>
>
> I guess this problem is not unique to PostgreSQL.  I think PostgreSQL can be
> more friendly for normal users (who use external transaction manager), and
> does not need to be too conservative because of people who do irregular
> things.

I would say *using* an external transaction manager *is* the irregular
thing. The current default *is* friendly for normal users, for example
see the comments from Andres about what happens if you make a mistake.
So I definitely agree with your sentiment that we should be more
friendly for normal users - but in this case we are.

If I look through all the customers I've worked with, only a handful
have actually used a transaction manager. And of those, at least half
of them were using it even though they didn't need it, because they
didn't know what it was.

But the argument about being friendly for new users should definitely
have us change wal_level and max_wal_senders.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: logical changeset generation v6.2
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Long paths for tablespace leads to uninterruptible hang in Windows