| Lists: | pgsql-hackers |
|---|
| From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
|---|---|
| To: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | pg_test_fsync output and commit_delay |
| Date: | 2012-09-08 21:26:21 |
| Message-ID: | CAEYLb_UEpG-6Nqk7Xqx94yu6xnoKTYcoAhL2PiMe2tScSrFPaQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
I propose that we try and develop better commit_delay advice, to make
it easier to set the parameter in a way that actually helps
performance. I have been researching a way to make commit_delay
adaptive, though have yet to develop any further insight that is worth
sharing. This may change.
The attached simple patch alters the output produced by pg_test_fsync,
so that we also see the average sync time per op. The pg_test_fsync
docs have had minor alterations too. Hopefully, another doc patch will
follow that builds upon this, and actually firmly recommends taking a
particular course of action when setting commit_delay - my previous
observations about what helped throughput, though supported by Greg
Smith, have not been scrutinised enough just yet, I feel. For now, the
equivocated wording of my doc alterations (that raw wal_sync_method
file sync time might *somehow* be useful here) seems appropriate.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
| Attachment | Content-Type | Size |
|---|---|---|
| pg_test_fsync.v1.2012_09_08.patch | application/octet-stream | 2.7 KB |
| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_test_fsync output and commit_delay |
| Date: | 2012-09-08 22:27:33 |
| Message-ID: | 504BC655.6080402@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
> The attached simple patch alters the output produced by pg_test_fsync,
> so that we also see the average sync time per op.
Good idea. A median would be even better, but harder to calculate, I
imagine. You might consider providing a maximum, too.
> The pg_test_fsync
> docs have had minor alterations too. Hopefully, another doc patch will
> follow that builds upon this, and actually firmly recommends taking a
> particular course of action when setting commit_delay - my previous
> observations about what helped throughput, though supported by Greg
> Smith, have not been scrutinised enough just yet, I feel. For now, the
> equivocated wording of my doc alterations (that raw wal_sync_method
> file sync time might *somehow* be useful here) seems appropriate.
I'll see what I can do.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com