Date: Thu, 1 Mar 2007 09:45:00 -0600
From: "Jim C. Nasby" <jim@nasby.net>
To: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Dead Space Map version 2
Message-ID: <20070301154459.GK15006@nasby.net>
References: <20070227141958.638D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
	<20070227170613.GK29041@nasby.net>
	<20070228154153.6733.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070228154153.6733.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
User-Agent: Mutt/1.5.13 (2006-08-11)

On Wed, Feb 28, 2007 at 04:10:09PM +0900, ITAGAKI Takahiro wrote:
> "Jim C. Nasby" <jim@nasby.net> 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                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)