From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "ml(at)bortal(dot)de" <ml(at)bortal(dot)de>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgres benchmarking with pgbench |
Date: | 2009-03-16 16:39:43 |
Message-ID: | alpine.GSO.2.01.0903161227130.13431@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-03-16 16:53:39 | Re: Proposal of tunable fix for scalability of 8.4 |
Previous Message | Matthew Wakeling | 2009-03-16 16:26:27 | Re: Proposal of tunable fix for scalability of 8.4 |