Re: Automatically setting work_mem
От | Martijn van Oosterhout |
---|---|
Тема | Re: Automatically setting work_mem |
Дата | |
Msg-id | 20060321222823.GJ11045@svana.org обсуждение исходный текст |
Ответ на | Re: Automatically setting work_mem (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Automatically setting work_mem
|
Список | 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 по дате отправления: