| From: | Duncan Kinnear <duncan(dot)kinnear(at)mccarthy(dot)co(dot)nz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, 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:42:33 |
| Message-ID: | 1463709613.1724361.1554849753257.JavaMail.zimbra@mccarthy.co.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
----- On 10 Apr, 2019, at 10:23 AM, Andres Freund andres(at)anarazel(dot)de wrote:
> 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.
Bingo! Adding 'SET LOCAL synchronous_commit TO OFF;' to my 'BEGIN; UPDATE ....; COMMIT;' block has given me sub-1ms timings! Thanks Andres.
I'll probably leave the setting as that on my local machine. The option appears to be relatively safe, but my machine is just a dev test machine anyway.
Regards,
Duncan Kinnear
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daulat Ram | 2019-04-10 05:40:25 | PostgreSQL upgrade. |
| Previous Message | Andres Freund | 2019-04-09 22:23:36 | Re: Commit(?) overhead |