Bruce Momjian <[EMAIL PROTECTED]> 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
measure.
>> * 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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
