Re: Automatically setting work_mem - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Automatically setting work_mem
Date
Msg-id 20060317222934.GD7887@svana.org
Whole thread Raw
In response to Re: Automatically setting work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 17, 2006 at 04:45:17PM -0500, Tom Lane wrote:
> Hannu Krosing <hannu@skype.net> writes:
> > So perhaps we could keep the shaded_work_mem in actual shared memory,
> > and alloc it to processes from there ?
>
> No, that's utterly not reasonable, both from an allocation point of view
> (you'd have to make shared memory enormous, and not all platforms will
> like that) and from a locking point of view.

Perhaps we just need to tweak the memory allocation routines to use
mmap() for large allocations rather than malloc(). Then they can be
easily returned to the system unlike the system heap. glibc does this
automatically sometimes.

Though you have to be careful, continuous mmap()/munmap() is more
expensive than malloc()/free() because mmap()ed memory must be zerod
out, which costs cycles...

Have a nice 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: Darcy Buskermolen
Date:
Subject: Re: Seperate command-line histories for seperate databases
Next
From: Josh Berkus
Date:
Subject: PostgreSQL Anniversary Proposals -- Important Update