From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Auto-tuning work_mem and maintenance_work_mem |
Date: | 2013-10-10 18:18:28 |
Message-ID: | 5256EF74.4090906@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce,
>> That's way low, and frankly it's not worth bothering with this if all
>> we're going to get is an incremental increase. In that case, let's just
>> set the default to 4MB like Robert suggested.
>
> Uh, well, 100 backends at 6MB gives us 600MB, and if each backend uses
> 3x work_mem, that gives us 1.8GB for total work_mem. This was based on
> Andrew's concerns about possible over-commit of work_mem. I can of
> course adjust that.
That's worst-case-scenario planning -- the 3X work-mem per backend was:
a) Solaris and
b) data warehousing
In a normal OLTP application each backend averages something like 0.25 *
work_mem, since many queries use no work_mem at all.
It also doesn't address my point that, if we are worst-case-scenario
default-setting, we're going to end up with defaults which aren't
materially different from the current defaults. In which case, why even
bother with this whole exercise?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-10-10 18:21:24 | Re: dynamic shared memory: wherein I am punished for good intentions |
Previous Message | Claudio Freire | 2013-10-10 18:18:13 | Re: dynamic shared memory: wherein I am punished for good intentions |