Re: [WIP PATCH] for Performance Improvement in Buffer Management

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP PATCH] for Performance Improvement in Buffer Management
Date: 2012-11-19 00:35:46
Message-ID: CAMkU=1xA1ACTrou3O-qigPS=FnX1AnhbGMsEn_-9sqAsrRdqeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 22, 2012 at 10:51 AM, Amit kapila <amit(dot)kapila(at)huawei(dot)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 happening for 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2012-11-19 00:44:03 Re: [WIP] pg_ping utility
Previous Message Michael Paquier 2012-11-19 00:31:13 Re: logical changeset generation v3