Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Sat, Apr 22, 2006 at 01:49:25PM -0700, David Fetter wrote: > On Sat, Apr 22, 2006 at 01:14:42PM -0700, David Gould wrote: > > > To avoid running out of swap and triggering the oom killer we have > > had to reduce work_mem below what we prefer. > > Dunno about your work_mem, but you can make su

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Sat, Apr 22, 2006 at 01:14:42PM -0700, David Gould wrote: > To avoid running out of swap and triggering the oom killer we have > had to reduce work_mem below what we prefer. Dunno about your work_mem, but you can make sure the OOM killer doesn't kill you as follows

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Sat, Apr 22, 2006 at 06:38:53PM +0100, Simon Riggs wrote: > On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote: > > Simon Riggs <[EMAIL PROTECTED]> writes: > > > I still do, for multi-user systems. Releasing unused memory from a large > > > CREATE INDEX will allow that memory to be swapped out, e

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Sat, 2006-04-22 at 13:17 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > I still do, for multi-user systems. Releasing unused memory from a large > > CREATE INDEX will allow that memory to be swapped out, even if the brk > > point can't be changed. > > Say what? It can get

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Sat, Apr 22, 2006 at 01:17:08PM -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > I still do, for multi-user systems. Releasing unused memory from a large > > CREATE INDEX will allow that memory to be swapped out, even if the brk > > point can't be changed. > > Say what? It

Re: [PATCHES] [HACKERS] Automatically setting work_mem

Simon Riggs <[EMAIL PROTECTED]> writes: > I still do, for multi-user systems. Releasing unused memory from a large > CREATE INDEX will allow that memory to be swapped out, even if the brk > point can't be changed. Say what? It can get "swapped out" anyway, whether we free() it or not. More to th

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Fri, 2006-04-21 at 23:07 -0400, Bruce Momjian wrote: > Where are we on this patch? Well the patches work and have been performance tested, with results posted. Again, the title of this thread doesn't precisely describe the patch any longer. The question is do people believe there is benefit in

Re: [PATCHES] [HACKERS] Automatically setting work_mem

Where are we on this patch? --- Simon Riggs wrote: > On Tue, 2006-03-21 at 17:47 -0500, Tom Lane wrote: > > > I'm fairly unconvinced about Simon's underlying premise --- that we > > can't make good use of work_mem in sortin

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Sat, Mar 25, 2006 at 12:24:00PM +, Simon Riggs wrote: > memory. Using too much memory could also impact overall elapsed time > when we have concurrent users, so the question is should we optimise > resources for the multi-user case or for the single user case? Where is > the right balance po

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Wed, 2006-03-22 at 10:03 +, Simon Riggs wrote: > Recent test results show that with a 512MB test sort we can reclaim > 97% of memory during final merge with only a noise level (+2%) > increase in overall elapsed time. (Thats just an example, your mileage > may vary). So a large query would

Re: [PATCHES] [HACKERS] Automatically setting work_mem

On Wed, 2006-03-22 at 07:48 +, Simon Riggs wrote: > On Tue, 2006-03-21 at 17:47 -0500, Tom Lane wrote: > > > I'm fairly unconvinced about Simon's underlying premise --- that we > > can't make good use of work_mem in sorting after the run building phase > > --- anyway. > > We can make good u