Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] fsync method checking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>,pgsql-performance(at)postgresql(dot)org,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] fsync method checking
Date: 2004-03-18 20:08:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> It's what tested out as the best bet.  I think we were using pgbench
>> as the test platform, which as you know I have doubts about, but at
>> least it is testing one actual write/sync pattern Postgres can generate.

> I assume pgbench has so much variance that trying to see fsync changes
> in there would be hopeless.

The results were fairly reproducible, as I recall; else we'd have looked
for another test method.  You may want to go back and consult the
pghackers archives.

>> * Some of the test cases count open()/close() overhead, some don't.

> The only one I saw that had an extra open() was the fsync after close
> test.  I add a do-nothing open/close to the previous test so they are
> the same.

Why is it sensible to include open/close overhead in the "simple write"
case and not in the "o_sync write" cases, for instance?  Doesn't seem
like a fair comparison to me.  Adding the open overhead to all cases
might make it "fair", but it would also make it not what we want to

>> * The program is claimed to test whether you can write from one process
>> and fsync from another, but it does no such thing AFAICS.

> It really just shows whether the fsync fater the close has similar
> timing to the one before the close.  That was the best way I could think
> to test it.

Sure, but where's the "separate process" part?  What this seems to test
is whether a single process can sync its own writes through a different
file descriptor; which is interesting but by no means the only thing we
need to be sure of if we want to make the bgwriter handle syncing.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Bruce MomjianDate: 2004-03-18 20:09:25
Subject: Re: [HACKERS] fsync method checking
Previous:From: Kurt RoeckxDate: 2004-03-18 20:03:59
Subject: Re: [HACKERS] fsync method checking

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-03-18 20:09:25
Subject: Re: [HACKERS] fsync method checking
Previous:From: Neil ConwayDate: 2004-03-18 20:06:21
Subject: compile warning in CVS HEAD

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group