Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Automatically setting work_mem

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Luke Lonergan <llonergan(at)greenplum(dot)com>,pgsql-patches(at)postgresql(dot)org,Martijn van Oosterhout <kleptog(at)svana(dot)org>,Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Automatically setting work_mem
Date: 2006-04-22 17:26:19
Message-ID: 20060422172619.GC49405@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Sat, Apr 22, 2006 at 01:17:08PM -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> 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 the point, though: I don't believe that the proposed patch is a
> good idea --- it does not reduce the peak sortmem use, which I think is
> the critical factor for a multiuser system, and what it does do is
> reduce the locality of access to the sort temp file during the merge
> phases.  That will definitely have some impact; maybe small, but some;
> and I don't see where the benefit comes in.

Do we have any info on how long the final phase of a sort typically
takes compared to the rest of the sort? If it can take a substantial
amount of time, then reducing the memory usage during that time will at
least allow the OS to use that memory for caching again. In the future,
if we have a better means of controlling sort memory usage, then freeing
the memory earlier would also put it back in the pool earlier, which
would benefit the multiple concurrent sorts case.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-04-22 17:34:42
Subject: Re: TODO items..
Previous:From: Tom LaneDate: 2006-04-22 17:17:08
Subject: Re: [HACKERS] Automatically setting work_mem

pgsql-patches by date

Next:From: Simon RiggsDate: 2006-04-22 17:38:53
Subject: Re: [HACKERS] Automatically setting work_mem
Previous:From: Tom LaneDate: 2006-04-22 17:17:08
Subject: Re: [HACKERS] Automatically setting work_mem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group