Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
От | Bruce Momjian |
---|---|
Тема | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
Дата | |
Msg-id | 20140515142425.GB25053@momjian.us обсуждение исходный текст |
Ответ на | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: proposal: Set effective_cache_size to greater of .conf
value, shared_buffers
|
Список | pgsql-hackers |
On Thu, May 15, 2014 at 10:23:19PM +0900, Amit Langote wrote: > On Thu, May 15, 2014 at 9:06 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > > This is the same problem we had with auto-tuning work_mem, in that we > > didn't know what other concurrent activity was happening. Seems we need > > concurrent activity detection before auto-tuning work_mem and > > effective_cache_size. > > > > Perhaps I am missing something obvious here, but would mmgr have any > useful numbers on this? Like any book-keeping info maintained by > mcxt.c/aset.c? Would extending that interface help? No, all memory allocat is per-process, except for shared memory. We probably need a way to record our large local memory allocations in PGPROC that other backends can see; same for effective cache size assumptions we make. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: