Re: Auto-tuning work_mem and maintenance_work_mem

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, 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-09 16:41:53
Message-ID: 20131009164153.GG2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> I think we should try to hit the existing defaults, which would mean we
> would use this computation:

For my 2c, I was hoping this would improve things for our users by
raising the tiny 1M default work_mem, so I don't agree that we should
simply be coming up with an algorithm to hit the same numbers we already
have today.

> (shared_buffers / 4) / max_connections + 768k / BUFSZ
>
> This would give us for a default 128MB shared buffers and 100
> max_connections:
>
> (16384 / 4) / 100 + (768 * 1024) / 8192
>
> which gives us 136, and that is 136 * 8192 or 1088k, close to 1MB.
>
> For 10x shared buffers, 163840, it gives a work_mem of 4040k, rather
> than the 10M I was computing in the original patch.
>
> How is that?

So this would only help if people are already going in and modifying
shared_buffers, but not setting work_mem? I'd rather see better
defaults for users that don't touch anything, such as 4MB or even
larger.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-10-09 16:52:03 Re: Auto-tuning work_mem and maintenance_work_mem
Previous Message Stephen Frost 2013-10-09 16:30:22 Re: Auto-tuning work_mem and maintenance_work_mem