From: Greg Smith <gsmith@gregsmith.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: ml@bortal.de <ml@bortal.de>
Cc: pgsql-performance@postgresql.org
Subject: Re: Postgres benchmarking with pgbench
Date: Mon, 16 Mar 2009 12:39:43 -0400 (EDT)
Message-ID: <alpine.GSO.2.01.0903161227130.13431@westnet.com> (raw)
In-Reply-To: <87bps132t1.fsf@oxford.xeocode.com>
References: <49BE2E84.2040506@bortal.de>
<alpine.GSO.2.01.0903161052430.9846@westnet.com>
<87bps132t1.fsf@oxford.xeocode.com>
On Mon, 16 Mar 2009, Gregory Stark wrote:
> Why would checkpoints force out any data? It would dirty those pages and then
> sync the files marking them clean, but they should still live on in the
> filesystem cache.
The bulk of the buffer churn in pgbench is from the statement that updates
a row in the accounts table. That constantly generates updated data block
and index block pages. If you can keep those changes in RAM for a while
before forcing them to disk, you can get a lot of benefit from write
coalescing that goes away if constant checkpoints push things out with a
fsync behind them.
Not taking advantage of that effectively reduces the size of the OS cache,
because you end up with a lot of space holding pending writes that
wouldn't need to happen at all yet were the checkpoints spaced out better.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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: gsmith@gregsmith.com, stark@enterprisedb.com, ml@bortal.de
Subject: Re: Postgres benchmarking with pgbench
In-Reply-To: <alpine.GSO.2.01.0903161227130.13431@westnet.com>
* 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