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

From Jeff Janes
Subject Re: [WIP PATCH] for Performance Improvement in Buffer Management
Date
Msg-id CAMkU=1xA1ACTrou3O-qigPS=FnX1AnhbGMsEn_-9sqAsrRdqeQ@mail.gmail.com
Whole thread Raw
In response to Re: [WIP PATCH] for Performance Improvement in Buffer Management  (Amit kapila <amit.kapila@huawei.com>)
Responses Re: [WIP PATCH] for Performance Improvement in Buffer Management  (Amit kapila <amit.kapila@huawei.com>)
List pgsql-hackers
On Mon, Oct 22, 2012 at 10:51 AM, Amit kapila <amit.kapila@huawei.com> wrote:
>

> Today again I have again collected the data for configuration Shared_buffers = 7G along with vmstat.
> The data and vmstat information (bi) are attached with this mail. It is observed from vmstat info that I/O is
happeningfor both cases, however after running for
 
> long time, the I/O is also comparatively less with new patch.

What I see in the vmstat report is that it takes 5.5 "runs" to get
really good and warmed up, and so it crawls for the first 5.5
benchmarks and then flies for the last 0.5 benchmark.  The way you
have your runs ordered, that last 0.5 of a benchmark is for the
patched version, and this drives up the average tps for the patched
case.

Also, there is no theoretical reason to think that your patch would
decrease the amount of IO needed (in fact, by invalidating buffers
early, it could be expected to increase the amount of IO).  So this
also argues that the increase in performance is caused by the decrease
in IO, but the patch isn't causing that decrease, it merely benefits
from it due to an accident of timing.

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: logical changeset generation v3
Next
From: Michael Paquier
Date:
Subject: Re: [WIP] pg_ping utility