Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9CC15633B36 for ; Mon, 16 Mar 2009 13:39:55 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 74550-05 for ; Mon, 16 Mar 2009 13:39:52 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by mail.postgresql.org (Postfix) with ESMTP id 2DA1A6330E9 for ; Mon, 16 Mar 2009 13:39:52 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id n2GGdhkd018913; Mon, 16 Mar 2009 12:39:43 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id n2GGdh6f018910; Mon, 16 Mar 2009 12:39:43 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Mon, 16 Mar 2009 12:39:43 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Gregory Stark cc: "ml@bortal.de" , pgsql-performance@postgresql.org Subject: Re: Postgres benchmarking with pgbench In-Reply-To: <87bps132t1.fsf@oxford.xeocode.com> Message-ID: References: <49BE2E84.2040506@bortal.de> <87bps132t1.fsf@oxford.xeocode.com> User-Agent: Alpine 2.01 (GSO 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/212 X-Sequence-Number: 33134 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