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
Date: Thu, 1 Mar 2007 09:45:00 -0600
Message-ID: <20070301154459.GK15006@nasby.net> (raw)
In-Reply-To: <20070228154153.6733.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
References: <20070227141958.638D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
<20070227170613.GK29041@nasby.net>
<20070228154153.6733.ITAGAKI.TAKAHIRO@oss.ntt.co.jp>
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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jim@nasby.net, itagaki.takahiro@oss.ntt.co.jp, pgsql-hackers@postgresql.org
Subject: Re: Dead Space Map version 2
In-Reply-To: <20070301154459.GK15006@nasby.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox