From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: multi-threaded pgbench |
Date: | 2009-07-08 16:38:05 |
Message-ID: | alpine.GSO.2.01.0907081227570.18239@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 8 Jul 2009, Itagaki Takahiro wrote:
> Multi-threading would be a solution. The attached patch adds -j
> (number of jobs) option to pgbench.
Should probably name this -w "numbers of workers" to stay consistent with
terminology used on the server side.
> Is it acceptable to use pthread in contrib module?
> If ok, I will add the patch to the next commitfest.
pgbench is basically broken right now, as demonstrated by the lack of
scaling show in your results and similar ones I've collected. This looks
like it fixes the primary problem there. While it would be nice if a
multi-process based solution were written instead, unless someone is
willing to step up and volunteer to write one I'd much rather see your
patch go in than doing nothing at all. It shouldn't even impact old
results if you don't toggle the option on.
I have 3 new server systems I was going to run pgbench on anyway in the
next month as part of my standard performance testing on new hardware.
I'll be happy to mix in results using the multi-threaded pgbench to check
the patch's performance, along with the rest of the initial review here.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-08 16:40:37 | Re: multi-threaded pgbench |
Previous Message | Andrew Gierth | 2009-07-08 16:30:08 | 8.4.0 vs. locales vs. pl/perl? |