2010/5/8 Bernd Helmle <mailings@oopsware.de>:
>
>
> --On 7. Mai 2010 09:48:53 -0500 Kevin Grittner <Kevin.Grittner@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