From: Greg Smith <greg@2ndquadrant.com>
To: Greg Stark <gsstark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pierre C <lists@peufeu.com>
Cc: Dave Crooke <dcrooke@gmail.com>
Cc: Paul McGarry <paul@paulmcgarry.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: shared_buffers advice
Date: Tue, 16 Mar 2010 16:53:24 -0400
Message-ID: <4B9FEFC4.1020705@2ndquadrant.com> (raw)
In-Reply-To: <407d949e1003160753o6e5faa48rabaa42f7548029b7@mail.gmail.com>
References: <a056b1d41003101728h2bfe964cg43bf5ef1aabae14d@mail.gmail.com>
<ca24673e1003152217q117b0fd3q7d2d75ff20185c8b@mail.gmail.com>
<4B9F3302.4020900@2ndquadrant.com>
<op.u9nrbeeteorkce@localhost>
<8285.1268749832@sss.pgh.pa.us>
<407d949e1003160753o6e5faa48rabaa42f7548029b7@mail.gmail.com>
Greg Stark wrote:
> On Tue, Mar 16, 2010 at 2:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> "Pierre C" <lists@peufeu.com> writes:
>>
>>> Does PG issue checkpoint writes in "sorted" order ?
>>>
>> No. IIRC, a patch for that was submitted, and rejected because no
>> significant performance improvement could be demonstrated.
> If the OS filesystem buffer cache is really small then that might not
> work so well. It might be worth rerunning those benchmarks on a
> machine with shared buffers taking up all of RAM.
>
Here's the original patch again:
http://archives.postgresql.org/message-id/20080415181742.6C97.52131E4D@oss.ntt.co.jp
I was the person who tried to reproduce the suggested 10% pgbench
speedup on a similar system and couldn't replicate any improvement.
Never was sure what was going on to show such a difference on the
reference system used to develop the patch versus mine, since they were
pretty similar. Possibly some positive interaction with LVM in the test
case I didn't have. Maybe the actual reason sorting helped was
limitations in the HP P400 controller used there I wasn't running into
with the Areca card I used. And the always popular "didn't account
fully for all pgbench run to run variation" possibility crossed my mind
too--that the original observed speedup wasn't caused by the patch but
by something else.
I did not go out of my way to find test conditions where the patch would
more likely to help, like the situation you describe where
shared_buffers was really large relative to the OS cache. Since the
patch complicates the checkpoint code and requires some working memory
to operate, it would have to be a unquestionable win using standard
practices before it was worth applying. If it only helps in a situation
people are unlikely to use in the field, and it net negative for
everyone else, that's still going to end up on the interesting but
rejected idea scrapheap at the end of the day.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
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: greg@2ndquadrant.com, gsstark@mit.edu, tgl@sss.pgh.pa.us, lists@peufeu.com, dcrooke@gmail.com, paul@paulmcgarry.com
Subject: Re: shared_buffers advice
In-Reply-To: <4B9FEFC4.1020705@2ndquadrant.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