Re: Auto-tuning work_mem and maintenance_work_mem

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: MauMau <maumau307(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Auto-tuning work_mem and maintenance_work_mem
Date: 2013-10-15 12:52:47
Message-ID: CABUevEz1fqRnncrYLtF8-U3wSrJo4tJCZsr6D+06W1r2W0JgiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 15, 2013 at 2:47 PM, MauMau <maumau307(at)gmail(dot)com> wrote:
> From: "Dimitri Fontaine" <dimitri(at)2ndQuadrant(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-10-15 12:55:49 Re: Long paths for tablespace leads to uninterruptible hang in Windows
Previous Message Robert Haas 2013-10-15 12:49:26 Re: logical changeset generation v6.2