Skip site navigation (1) Skip section navigation (2)

Re: Dead Space Map version 2

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dead Space Map version 2
Date: 2007-03-01 15:45:00
Message-ID: 20070301154459.GK15006@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patchespgsql-performance
On Wed, Feb 28, 2007 at 04:10:09PM +0900, ITAGAKI Takahiro wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)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(at)nasby(dot)net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

In response to

pgsql-performance by date

Next:From: Joshua D. DrakeDate: 2007-03-01 15:47:28
Subject: Re: increasing database connections
Previous:From: Rob SchallDate: 2007-03-01 15:43:25
Subject: Identical Queries

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2007-03-01 15:49:06
Subject: Re: Revitalising VACUUM FULL for 8.3
Previous:From: Zeugswetter Andreas ADI SDDate: 2007-03-01 15:43:01
Subject: Re: HOT - preliminary results

pgsql-patches by date

Next:From: Tom LaneDate: 2007-03-01 15:52:44
Subject: Re: Fast COPY after TRUNCATE bug and fix
Previous:From: Peter EisentrautDate: 2007-03-01 14:55:37
Subject: Re: correct format for date, time, timestamp for XML functionality

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group