Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?) - Mailing list pgsql-general

From Michael Lewis
Subject Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)
Date
Msg-id CAHOFxGqmM5i_z_urcFGoAq0tTd4MVQ+wGNyinWzN1USmQVxQWg@mail.gmail.com
Whole thread Raw
In response to Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general
On Tue, Aug 27, 2019 at 9:45 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
Holtgrewe, Manuel wrote:
> Switching off fsync leads to a drastic time improvement but still
> higher wall-clock time for four threads.

Don't do that unless you are ready to start from scratch with a new
"initdb" in the case of a crash.

You can do almost as good by setting "synchronous_commit = off",
and that is crash-safe.

It seems like it depends on your definition of crash-safe. Data loss can occur but not data corruption, right? Do you know any ballpark for how much difference in performance it makes to turn off synchronous_commit or what type of hardware or usage it would make the biggest (or least) difference?

pgsql-general by date:

Previous
From: Vijaykumar Jain
Date:
Subject: wal_level logical for streaming replication
Next
From: francis picabia
Date:
Subject: Re: How to log 'user time' in postgres logs