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

Re: Dead Space Map version 2

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dead Space Map version 2
Date: 2007-02-27 08:38:39
Message-ID: 20070227141958.638D.ITAGAKI.TAKAHIRO@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patchespgsql-performance
"Jim C. Nasby" <jim(at)nasby(dot)net> wrote:

> > If we do UPDATE a tuple, the original page containing the tuple is marked
> > as HIGH and the new page where the updated tuple is placed is marked as LOW.
> 
> Don't you mean UNFROZEN?

No, the new tuples are marked as LOW. I intend to use UNFROZEN and FROZEN
pages as "all tuples in the pages are visible to all transactions" for
index-only-scan in the future.


> What makes it more important to mark the original page as HIGH instead
> of LOW, like the page with the new tuple? The description of the states
> indicates that there would likely be a lot more dead tuples in a HIGH
> page than in a LOW page.
> 
> Perhaps it would be better to have the bgwriter take a look at how many
> dead tuples (or how much space the dead tuples account for) when it
> writes a page out and adjust the DSM at that time.

Yeah, I feel it is worth optimizable, too. One question is, how we treat
dirty pages written by backends not by bgwriter? If we want to add some
works in bgwriter, do we also need to make bgwriter to write almost of
dirty pages?


> > * Agressive freezing
> >     We will freeze tuples in dirty pages using OldestXmin but FreezeLimit.
> 
> Do you mean using OldestXmin instead of FreezeLimit?

Yes, we will use OldestXmin as the threshold to freeze tuples in
dirty pages or pages that have some dead tuples. Or, many UNFROZEN
pages still remain after vacuum and they will cost us in the next
vacuum preventing XID wraparound.


> > I'm thinking to change them into 2 new paramaters. We will allocates memory
> > for DSM that can hold all of estimated_database_size, and for FSM 50% or
> > something of the size. Is this reasonable?
>  
> I don't think so, at least not until we get data from the field about
> what's typical. If the DSM is tracking every page in the cluster then
> I'd expect the FSM to be closer to 10% or 20% of that, anyway.

I'd like to add some kind of logical flavors to max_fsm_pages
and max_dsm_pages. For DSM, max_dsm_pages should represent the
whole database size. In the other hand, what meaning does
max_fsm_pages have? (estimated_updatable_size ?)

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center



In response to

Responses

pgsql-performance by date

Next:From: ITAGAKI TakahiroDate: 2007-02-27 08:56:23
Subject: Re: Dead Space Map version 2
Previous:From: Peter KovacsDate: 2007-02-27 08:27:52
Subject: Re: Two hard drives --- what to do with them?

pgsql-hackers by date

Next:From: ITAGAKI TakahiroDate: 2007-02-27 08:56:23
Subject: Re: Dead Space Map version 2
Previous:From: Simon RiggsDate: 2007-02-27 08:16:54
Subject: Re: Dead Space Map version 2

pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-02-27 08:56:12
Subject: Re: POSIX shared memory support
Previous:From: Simon RiggsDate: 2007-02-27 08:16:54
Subject: Re: Dead Space Map version 2

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