From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]> > Tom Lane <[EMAIL PROTECTED]> 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." ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
