On Mon, Oct 22, 2012 at 10:51 AM, Amit kapila <amit.kap...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
