Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)

Поиск
Список
Период
Сортировка
От Michael Lewis
Тема Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)
Дата
Msg-id CAHOFxGqmM5i_z_urcFGoAq0tTd4MVQ+wGNyinWzN1USmQVxQWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: [ext] Re: Pointers towards identifying bulk import bottleneck(walwriter tuning?)  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список 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 по дате отправления:

Предыдущее
От: Vijaykumar Jain
Дата:
Сообщение: wal_level logical for streaming replication
Следующее
От: francis picabia
Дата:
Сообщение: Re: How to log 'user time' in postgres logs