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

Re: Logging checkpoints and other slowdown causes

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Logging checkpoints and other slowdown causes
Date: 2007-05-30 04:09:29
Message-ID: Pine.GSO.4.64.0705292337150.12775@westnet.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Tue, 29 May 2007, Heikki Linnakangas wrote:

> The checkpoint will take at least a couple of seconds on any interesting 
> system, so 0.1 s resolution should be enough IMHO.

You may be underestimating the resources some interesting systems are 
willing to put into speeding up checkpoints.  I'm sometimes dumping into a 
SAN whose cache is bigger than the shared_buffer cache in the server, and 
0.1s isn't really enough resolution in that situation.  A second is a 
really long checkpoint there.  Since even that's limited by fiber-channel 
speeds, I know it's possible to do better than what I'm seeing with 
something like a PCIe host adapter having on-board cache in the GB range 
(which isn't that expensive nowadays).

Also, even if the checkpoint total takes seconds, much of that is in the 
sync phase; the write time can still be in the small number of ms range, 
and I wouldn't want to see that truncated too much.

Anyway, I have a bunch of data on this subject being collected at this 
moment, and I'll rescale the results based on what I see after analyzing 
that this week.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

pgsql-hackers by date

Next:From: Hannes EderDate: 2007-05-30 10:09:05
Subject: Re: msvc, build and install with cygwin in the PATH
Previous:From: Bruce MomjianDate: 2007-05-30 03:37:44
Subject: Re: TOAST usage setting

pgsql-patches by date

Next:From: Hannes EderDate: 2007-05-30 10:09:05
Subject: Re: msvc, build and install with cygwin in the PATH
Previous:From: Tom LaneDate: 2007-05-30 04:02:11
Subject: Re: WIP: 2nd-generation buffer ring patch

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