Re: Auto-tuning work_mem and maintenance_work_mem

On Wed, Oct 9, 2013 at 12:41:53PM -0400, Stephen Frost wrote:
> * 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.

OK, but changing the default if shared_buffers is _not_ changed is a
separate discussion.

We can have the discussion here or in another thread. I am thinking the
right fix is to allocate larger shared_buffers, especially now that we
don't require a larger System V shared memory segement. Basically, for
128MB of shared buffers, I figured the calculation was fine, and when we
increase the default shared_buffers, we will then get a better default,
which is why I am quoting the 2GB shared_buffers defaults in my emails.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +