Re: Dynamically sizing FSM?

"Bruce Momjian" <bruce(at)momjian(dot)us> 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