Re: basic pgbench runs with various performance-related patches
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: pgsql-hackers@postgresql.org
Date: 2012-01-24T13:58:58Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Separate state from query string in pg_stat_activity
- 4f42b546fd87 9.2.0 cited
On Tue, Jan 24, 2012 at 1:26 AM, Tatsuo Ishii <ishii@postgresql.org> wrote: >> ** pgbench, permanent tables, scale factor 100, 300 s ** >> 1 group-commit-2012-01-21 614.425851 -10.4% >> 8 group-commit-2012-01-21 4705.129896 +6.3% >> 16 group-commit-2012-01-21 7962.131701 +2.0% >> 24 group-commit-2012-01-21 13074.939290 -1.5% >> 32 group-commit-2012-01-21 12458.962510 +4.5% >> 80 group-commit-2012-01-21 12907.062908 +2.8% > > Interesting. Comparing with this: > http://archives.postgresql.org/pgsql-hackers/2012-01/msg00804.php > you achieved very small enhancement. Do you think of any reason which > makes the difference? My test was run with synchronous_commit=off, so I didn't expect the group commit patch to have much of an impact. I included it mostly to see whether by chance it helped anyway (since it also helps other WAL flushes, not just commits) or whether it caused any regression. One somewhat odd thing about these numbers is that, on permanent tables, all of the patches seemed to show regressions vs. master in single-client throughput. That's a slightly difficult result to believe, though, so it's probably a testing artifact of some kind. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company