Re: -F option
От | Tom Lane |
---|---|
Тема | Re: -F option |
Дата | |
Msg-id | 14434.976586574@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | -F option (newsreader@mediaone.net) |
Ответы |
Re: -F option
|
Список | pgsql-novice |
newsreader@mediaone.net writes: > What I would like to know is what 'sometime later' means. > Is it one hour? 30 seconds? 30 minutes? 24 hours? On a typical unix setup it's the cycle length of your syncer daemon (typically 30 seconds), plus however long it physically takes the OS to push the data out to the drive and then the drive to get around to writing it. The nearby estimate of 1 minute sounds good to me as a (fairly conservative) upper bound, at least under normal conditions. The standard advice about -F is that it's cool if you trust your OS, your hardware, and your UPS. You do *not* need to worry about Postgres crashes --- the backend will write the data to the kernel at commit in any case. The only question is whether we try to encourage the kernel to push the data down to disk before we report that the transaction has been committed. There is a long thread on pghackers recently to the effect that even without -F, you are at the mercy of disk drive and power supply failures, because fsync() only guarantees that the kernel has given the data to the disk drive; modern disk drives may buffer the data for awhile before they plop it down onto the platter. So, you probably want a UPS in any case. Beyond that, how many kernel crashes and hardware failures have you seen lately? > My usage is frequent lookup of small pieces of information, > ocassionally insert of small pieces of information and even less > frequent update of small pieces of information. OTOH, if you are not doing a lot of insert/update/delete then -F gains little performance anyway... regards, tom lane
В списке pgsql-novice по дате отправления: