Fsync on/off For Various Filesystems/Platforms (Ending Note)

Started by Mark Kirkwoodabout 24 years ago3 messagesgeneral
Jump to latest
#1Mark Kirkwood
mark.kirkwood@catalyst.net.nz

Damn... too quick with the "send" button.

I forgot to mention :

1) the test involved usng copy to load the rows !
2) The masured numbers were elapsed minutes:seconds for the load

regards (again)

Mark

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mark Kirkwood (#1)
Re: Fsync on/off For Various Filesystems/Platforms (Ending Note)

Mark kirkwood <markir@slingshot.co.nz> writes:

I forgot to mention :
1) the test involved usng copy to load the rows !

Still not much help. Was it a single COPY command, or a bunch of them?

The fsync overhead is (and always has been) a per-transaction cost,
so a benchmark that gives you no idea how many transactions were
committed isn't much help. Also, if there was only one transaction
commit in your 5-minute benchmark run, then I can see why fsync would
be pretty irrelevant ... try something with one commit per inserted
row if you want to see a bigger penalty ...

regards, tom lane

#3Bruce Momjian
bruce@momjian.us
In reply to: Mark Kirkwood (#1)
Re: Fsync on/off For Various Filesystems/Platforms (Ending

Mark kirkwood wrote:

Damn... too quick with the "send" button.

I forgot to mention :

1) the test involved usng copy to load the rows !

Oh, COPY. Remember fsync of WAL only happens at the end of a
transaction, and with COPY, that is only once the table is completely
loaded. No wonder you saw strange results. Also, someone reported ext3
as 50% slower than ext2, so again, your numbers are a surprise.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026