On Wed, Feb 28, 2007 at 04:10:09PM +0900, ITAGAKI Takahiro wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > > > At some point it might make sense to convert the FSM into a bitmap; that > > way everything just scales with database size. > > > In the meantime, I'm not sure if it makes sense to tie the FSM size to > > the DSM size, since each FSM page requires 48x the storage of a DSM > > page. I think there's also a lot of cases where FSM size will not scale > > the same was DSM size will, such as when there's historical data in the > > database. > > Bitmapped FSM is interesting. Maybe strict accuracy is not needed for FSM. > If we change FSM to use 2 bits/page bitmaps, it requires only 1/48 shared > memory by now. However, 6 bytes/page is small enough for normal use. We need > to reconsider it if we would go into TB class heavily updated databases. > > > > That raises another question... what happens when we run out of DSM > > space? > > First, discard completely clean memory chunks in DSM. 'Clean' means all of > the tuples managed by the chunk are frozen. This is a lossless transition. > > Second, discard tracked tables and its chunks that is least recently > vacuumed. We can assume those tables have many dead tuples and almost > fullscan will be required. We don't bother to keep tracking to such tables. > > Many optimizations should still remain at this point, but I'll make > a not-so-complex suggestions in the meantime.
Actually, I have to agree with Heikki and Takayuki-san... I really like the idea of managing DSM (and FSM for that matter) using shared_buffers. If we do that, that means that we could probably back them to disk very easily. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
