>(Quoting Tom Lane)
>Still not much help. Was it a single COPY command, or a bunch of them?
>
Err..clearly should not send messages in the evening :-(
One single process was doing the load - so there is 1 big copy , and 1
transaction.
>try something with one commit per inserted
>row if you want to see a bigger penalty ...
you are indeed right. We were (attempting) to determine the penalty for
loads via copy - rather than determining bounds for the fsync=on penalty
in a general case (but we didnt actually say that).
In hindsight the posting was poorly named - something like :
"The effect of fsync on/off for a single threaded copy" would have been
a much better name.
>Also, if there was only one transaction
>commit in your 5-minute benchmark run, then I can see why fsync would
>be pretty irrelevant ...
So I was expecting to see pretty much no effect for fsync on vs off.
Which is pretty much what we saw - except for ext3, where that single
5-min transaction got an extra 30s added to it for fsync=on
This is what I thought was interesting - I guess maybe the ext3
development lists may have been a better place do the post.
(Quoting Bruce Momjian)
>Also, someone reported ext3
>as 50% slower than ext2, so again, your numbers are a surprise.
I found myself thinking "what mount options and journal sizes option did
they use?", which prompted me to include the ones I used (data=ordered &
100M journal ) - another small oversight :-(.
If I use data=journal + a small (say 20M) journal then I am sure I can
approach your 50%...
Regards and apologies for the several confusions
Mark
