Re: Dynamically sizing FSM?
От | ITAGAKI Takahiro |
---|---|
Тема | Re: Dynamically sizing FSM? |
Дата | |
Msg-id | 20070111114553.55E2.ITAGAKI.TAKAHIRO@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Dynamically sizing FSM? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > > What do you think dynamic allocation from shared_buffers? ie, remove > > a buffer page in the shared buffer pool and use the 8kB of memory > > for another purpose. > > The problem with that is that (a) it creates more contention load on the > shared buffer pool's management structures, and (b) if the chosen buffer > is dirty then you have a different subsystem trying to do buffer I/O, > which is at best a modularity bug and at worst a correctness or deadlock > problem. (a) I'm thinking that another hash table manages removed buffers. Those buffers are marked with a new BM_SPECIAL flags or something in BufferDesc->flags. We lookup them through module-specific hash tables, so that buffer management hash tables (BufTable) are not used. (b) Maybe we need a new abstraction layer under the buffer cache module. A new "memory pool" subsystem will preserve our sanity. +-- shared memory pool <- no more than "a bank of memory" +-- page cache <- currently called "shared buffers" +--other modules using shared buffers > It might represent a slightly > inefficient use of the shared memory as a whole, but it helps preserve > the developers' sanity ;-) Yeah, I see. That's a bother :-) But are there any requests to resize memory resources at runtime? I want to use the dynamic shmem allocator for FSM and DSM if available. If anyone want to use it for another purpose, inventing it as a generalized form will be good. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: