"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Josh Berkus wrote: >> All, >> >> Hey, is there any good reason why FSM is sized by a static GUC variable? >> Why couldn't we just automatically have the system use as much memory as >> it needs for FSM, provided that it's not more than some reasonable limit, >> like 15% of shared memory? >> >> Seems like that would eliminate one area of user confusion, as well as >> over-allocation. > > I don't think any of our shared memory segments auto-size. What would > you take memory from to increase FSM?
The obvious answer to this question is the shared buffer cache. The real problem is that we don't have, and don't particularly want, a memory manager for the shared memory. So where and how do you keep track of which memory is being used for what? You could sort of get it for free by just using the buffer manager to open FSM data files -- even getting spilling to disk of FSM data for rarely used relations for free. But then you would be fighting so much machinery, for example, log flushing buffers before flushing, that it might be easier to just have a separate data structure. I think replacing the FSM with something more flexible is on several developers' long-term todo lists, but it's not entirely clear yet -- at least to me -- what features we need. Someone working on vacuum or bgwriter improvements will probably find the FSM a stumbling block along the way and know better what needs to be done to it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
