On Thu, May 15, 2014 at 11:24 PM, Bruce Momjian <br...@momjian.us> wrote: > On Thu, May 15, 2014 at 10:23:19PM +0900, Amit Langote wrote: >> On Thu, May 15, 2014 at 9:06 PM, Bruce Momjian <br...@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. >
I see. I thought there would be some centralised way to traverse, say, a linked list of contexts that individual backends create or something like that. But, I suppose it would not be straightforward to make any of that work for what we are after here. -- Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
