Re: [WIP PATCH] for Performance Improvement in Buffer Management - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [WIP PATCH] for Performance Improvement in Buffer Management
Date
Msg-id 008301cdb030$c082d190$418874b0$@kapila@huawei.com
Whole thread Raw
In response to Re: [WIP PATCH] for Performance Improvement in Buffer Management  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Saturday, October 20, 2012 11:07 PM  Jeff Janes wrote:
> On Fri, Oct 19, 2012 at 11:00 PM, Amit kapila <amit.kapila@huawei.com>
> wrote:
> >
> >> Robert wrote an accounting patch a while ago that tallied how often a
> >> buffer was cleaned but then reclaimed for the same page before being
> >> evicted.  But now I can't find it.  If you can find that thread,
> there
> >> might be some benchmarks posted to it that would be useful.
> >
> > In my first level search, I am also not able to find it. But now I am
> planning to check all
> > mails of Robert Haas on PostgreSQL site (which are approximately
> 13,000).
> > If you can tell me how long ago approximately (last year, 2 yrs back,
> ..) or whether such a patch is submitted
> > to any CF or was just discussed in mail chain, then it will be little
> easier for me.
> 
> It was just an instrumentation patch for doing experiments, not
> intended for commit.
> 
> I've tracked it down to the thread "Initial 9.2 pgbench write
> results".  But I don't think it applies to the -S benchmark, because
> it records when the background writer cleaned a buffer by finding it
> dirty and writing it out to make it clean, while in this situation we
> would need something more like "either made the buffer clean and
> reusable, observed the buffer to already be clean and reusable"

Do you think an instrumentation patch which can give us how many times a
buffer is found by Clock Sweep and how many times it's found from freelist
will be useful?
I have written something on similar lines when I was testing this patch to
find out how many times this patch can avoid clock sweep.
My observation was that although the new implementation saves many cycles of
clock sweep, but still with shared buffers upto 2,2.5G there is no visible
performance gain.

With Regards,
Amit Kapila.




pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: assertion failure w/extended query protocol
Next
From: Marko Tiikkaja
Date:
Subject: Re: pg_dump --split patch