| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Duncan Kinnear <duncan(dot)kinnear(at)mccarthy(dot)co(dot)nz>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Commit(?) overhead |
| Date: | 2019-04-09 22:23:36 |
| Message-ID: | 20190409222336.45ekgwcj4ot3zxkq@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
On 2019-04-09 17:12:27 -0500, Justin Pryzby wrote:
> You could test that's the issue by comparing with fsync=off (please read what
> that means and don't run your production cluster like that).
> https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-FSYNC
I suggest testing it with synchronous_commit=off instead. That's about
as fast for this type of workload, doesn't have cluster corruption
issues, the window of a transaction not persisting in case of a crash is
very small, and it can just set by any user in individual sessions.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Duncan Kinnear | 2019-04-09 22:42:33 | Re: Commit(?) overhead |
| Previous Message | Justin Pryzby | 2019-04-09 22:12:27 | Re: Commit(?) overhead |