Re: [HACKERS] Automatically setting work_mem - Mailing list pgsql-patches

From Jim C. Nasby
Subject Re: [HACKERS] Automatically setting work_mem
Date
Msg-id 20060422172619.GC49405@pervasive.com
Whole thread Raw
In response to Re: [HACKERS] Automatically setting work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Sat, Apr 22, 2006 at 01:17:08PM -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Automatically setting work_mem
Next
From: Tom Lane
Date:
Subject: Re: patch to have configure check if CC is intel C compiler