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

Re: Load Distributed Checkpoints, take 3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Load Distributed Checkpoints, take 3
Date: 2007-06-22 14:10:38
Message-ID: 21532.1182521438@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> (BTW, the patch seems
>> a bit schizoid about whether checkpoint_rate is int or float.)

> Yeah, I've gone back and forth on the data type. I wanted it to be a 
> float, but guc code doesn't let you specify a float in KB, so I switched 
> it to int.

I seriously question trying to claim that it's blocks at all, seeing
that the *actual* units are pages per unit time.  Pretending that it's
a memory unit does more to obscure the truth than document it.

>> What's bugging me about this is that we are either going to be writing
>> at checkpoint_rate if ahead of schedule, or max possible rate if behind;
>> that's not "smoothing" to me, that's introducing some pretty bursty
>> behavior.

> That sounds a lot more complex. The burstiness at that level shouldn't 
> matter much. The OS is still going to cache the writes, and should even 
> out the bursts.

With the changes you're proposing here, the burstiness would be quite
severe.  OTOH, if writes_per_nap is always 1, then bufmgr is going to
recheck the delay situation after every page, so what you have actually
tested is as granular as it could get.

>> And checkpoint_rate really needs to be named checkpoint_min_rate, if
>> it's going to be a minimum.  However, I question whether we need it at
>> all,

> Hmm. With bgwriter_delay of 200 ms, and checkpoint_min_rate of 512 KB/s, 
>   using the non-broken formula above, we get:

> (512*1024/8192) * 200 / 1000 = 12.8, truncated to 12.

> So I think that's fine.

"Fine?"  That's 12x the value you have actually tested.  That's enough
of a change to invalidate all your performance testing IMHO.  I still
think you've not demonstrated a need to expose this parameter.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-06-22 14:22:38
Subject: Re: Transaction Guarantee, updated version
Previous:From: Bruce MomjianDate: 2007-06-22 13:12:22
Subject: Re: Load Distributed Checkpoints, take 3

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