Re: Automatically setting work_mem - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Automatically setting work_mem
Date
Msg-id 20060321222823.GJ11045@svana.org
Whole thread Raw
In response to Re: Automatically setting work_mem  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Automatically setting work_mem
List pgsql-hackers
On Tue, Mar 21, 2006 at 08:05:50PM +0000, Simon Riggs wrote:
> > Point 2 is actually a serious flaw in Simon's proposal, because there
> > is no portable way to make malloc return freed memory to the OS.  Some
> > mallocs will do that ... in some cases ... but many simply don't ever
> > move the brk address down.  It's not an easy thing to do when the arena
> > gets cluttered with a lot of different alloc chunks and only some of
> > them get freed.

<snip>

> The largest requirement for memory is the run building during
> performsort. That portion of the code is not concurrently executed
> within the same query. If we can reduce memory usage after that phase
> completes then we stand a chance of not overusing memory on a big query
> and not being able to reclaim it.

There is one way to guarentee the memory is released to the OS after
completion. Make the allocator allocate work_mem bytes using mmap()
rather than malloc(). munmap() will then definitly return the memory to
the OS. Unfortunatly, the coding required would probably not be
straight-forward... Glibc will only convert malloc() to an mmap() on
allocations > 128KB  and I don't think PostgreSQL ever does that.

Have a ncie day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] A real currency type
Next
From: Martijn van Oosterhout
Date:
Subject: Re: [GENERAL] A real currency type