Re: basic pgbench runs with various performance-related patches
От | Robert Haas |
---|---|
Тема | Re: basic pgbench runs with various performance-related patches |
Дата | |
Msg-id | CA+TgmobCCm9svXYcOwFerSJmaNCjePrHYjm=ACxFWVYQ9fkxXA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: basic pgbench runs with various performance-related patches (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: basic pgbench runs with various performance-related
patches
Re: basic pgbench runs with various performance-related patches |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: