Re: Dynamically sizing FSM?

From: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> I'm of the opinion that the solution to FSM being fixed-size is to
keep
>> it somewhere else, ie, on disk (possibly with some sort of cache in
>> shared memory for currently-used entries).
>
> 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. To be sure, we don't free from
out-of-FSM-memory,
> but it can get rid of deciding the amount of FSM buffers.
> I think we could use the above as "shared memory allocator".
> It is useful for Dead Space Map, shared prepared statements, and so
on.

Yes! I'm completely in favor of Itagaki-san. Separating the cache for
FSM may produce a new configuration parameter like fsm_cache_size,
which the normal users would not desire (unless they like enjoying
difficult DBMS.)
I think that integrating the treatment of space management structure
and data area is good. That means, for example, implementing "Free
Space Table" described in section 14.2.2.1 of Jim Gray's book
"Transaction Processing: Concepts and Techniques", though it may have
been discussed in PostgreSQL community far long ago (really?). Of
course, some refinements may be necessary to tune to PostgreSQL's
concept, say, creating one free space table file for each data file to
make the implementation easy. It would reduce the source code solely
for FSM.

In addition, it would provide the transactional space management. If
I understand correctly, in the current implementation, updates to FSM
are lost when the server crashes, aren't they? The idea assumes that
FSM will be rebuilt by vacuum because vacuum is inevitable. If
updates to space management area were made transactional, it might
provide the infrastructure for "vacuumless PostgreSQL."