From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hannu Krosing <hannu(at)skype(dot)net>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Automatically setting work_mem |
Date: | 2006-03-17 22:29:34 |
Message-ID: | 20060317222934.GD7887@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Fri, Mar 17, 2006 at 04:45:17PM -0500, Tom Lane wrote:
> Hannu Krosing <hannu(at)skype(dot)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(at)svana(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-03-18 01:52:48 | PostgreSQL Anniversary Proposals -- Important Update |
Previous Message | Darcy Buskermolen | 2006-03-17 22:28:31 | Re: Seperate command-line histories for seperate databases |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-18 05:59:16 | Re: Automatically setting work_mem |
Previous Message | Tom Lane | 2006-03-17 21:45:17 | Re: Automatically setting work_mem |