2010/5/8 Bernd Helmle <maili...@oopsware.de>: > > > --On 7. Mai 2010 09:48:53 -0500 Kevin Grittner <kevin.gritt...@wicourts.gov> > wrote: > >> I think it goes beyond "tweaking" -- I think we should have a bald >> statement like "don't turn this off unless you're OK with losing the >> entire contents of the database cluster." A brief listing of some >> cases where that is OK might be illustrative. >> > > +1 > >> I never meant to suggest any statement in that section is factually >> wrong; it's just all too rosy, leading people to believe it's no big >> deal to turn it off. > > I think one mistake in this paragraph is the passing mention of > "performance". I've seen installations in the past with fsync=off only > because the admin was pressured to get instantly "more speed" out of the > database (think of "fast_mode=on"). In my opinion, phrases like "performance > penalty" are misleading, if you need that setting in 99% of all use cases > for reliable operation. > > I've recently even started to wonder if the performance gain with fsync=off > is still that large on modern hardware. While testing large migration > procedures to a new version some time ago (on an admitedly fast storage) i > forgot here and then to turn it off, without a significant degradation in > performance.
On a recent pg_restore -j 32, with perc 6i with BBU, RAID10 8 hd, results were not so bas with fsync turn on. (XFS with nobarrier su and sw) -- deactivate fsync time pg_restore -U postgres -d foodb -j 32 foo.psql real 170m0.527s user 43m12.914s sys 1m56.499s -- activate fsync time pg_restore -U postgres -d foodb -j 32 foo.psql real 177m0.121s user 42m54.581s sys 2m0.452s > > > -- > Thanks > > Bernd > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers