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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2006-04-22 17:38:53 Re: [HACKERS] Automatically setting work_mem
Previous Message Tom Lane 2006-04-22 17:17:08 Re: [HACKERS] Automatically setting work_mem