Re: -F option, RAM usage, more...
От | Mitch Vincent |
---|---|
Тема | Re: -F option, RAM usage, more... |
Дата | |
Msg-id | 00c801c02e43$585f9700$0200000a@doot обсуждение исходный текст |
Ответ на | -F option, RAM usage, more... ("Mike Biamonte" <mike@dbeat.com>) |
Ответы |
Re: -F option, RAM usage, more...
|
Список | pgsql-general |
Hmm, it seems we all know just enough to be dangerous :-) I have seen many threads on the "to fsync() or not to fsync()" and overwhelmingly people have come out and said that to not fsync() is A Bad Thing(TM). -- If Neil is right then it being bad or not is going to depend very much on the filesystem (I think)... Now I'm pretty confused (as I'm sure others are) -- can someone that knows beyond a reasonable doubt beat us with a clue stick on this? Are we taking a huge risk if we use -F and disable fsync() or no? -Mitch ----- Original Message ----- From: "Neil Conway" <nconway@klamath.dyndns.org> To: <pgsql-general@hub.org> Sent: Wednesday, October 04, 2000 1:24 PM Subject: Re: [GENERAL] -F option, RAM usage, more... On Wed, Oct 04, 2000 at 02:09:47PM -0400, Mike Biamonte wrote: > I understand from the docs that -F ".. prevents fsync()'s from > flushing to disk after every transaction.." and that this boosts > performance because RAM accesses are far faster than disk accesses. I > have also seen some impressive stats regarding the degree of this > performance boost. Correct me if I'm wrong, but I believe that when you specify '-F', it allows the filesystem to buffer I/O operations, performing several operations once after another. This is much faster than with fsync(), where the disk heads have to be moved frequently. Also, allowing the I/O subsystem to buffer some data will speed subsequent accesses of it, until the buffer is flushed. HTH, Neil -- Neil Conway <neilconway@home.com> Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed Violence is to dictatorship as propaganda is to democracy. -- Noam Chomsky
В списке pgsql-general по дате отправления: