Re: Automatically setting work_mem

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Automatically setting work_mem
Дата
Msg-id 20060317222934.GD7887@svana.org
обсуждение исходный текст
Ответ на Re: Automatically setting work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Darcy Buskermolen
Дата:
Сообщение: Re: Seperate command-line histories for seperate databases
Следующее
От: Josh Berkus
Дата:
Сообщение: PostgreSQL Anniversary Proposals -- Important Update