Re: multi-threaded pgbench

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Josh Williams <joshwilliams(at)ij(dot)net>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: multi-threaded pgbench
Date: 2009-07-28 16:10:57
Message-ID: alpine.GSO.2.01.0907281204310.29621@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 28 Jul 2009, Josh Williams wrote:

> Maybe pgbench itself is less of a bottleneck in this environment,
> relatively speaking?

On UNIXish systems, you know you've reached the conditions under which the
threaded pgbench would be helpful if the pgbench client program itself is
taking up a large percentage of a CPY just by itself. If your test system
is still setup, it might be interesting to try the 64 and 128 client cases
with Task Manager open, to see what percentage of the CPU the pgbench
driver program is using. If the pgbench client isn't already pegged at a
full CPU, I wouldn't necessarily threading it to help--it would just add
overhead that doesn't buy you anything, which seems to be what you're
measuring.

All the Linux tests suggest that limit tends up show up at over 20,000 TPS
nowawadys, so maybe your Window system is bottlenecking somewhere
completely different before it reaches saturation on the client.

In any case, Josh's review is exactly what I wanted to see here--the code
does compile and run successfully for someone besides its author under
Windows. Making it *effective* on that platform might end up being
outside the scope of what we want to chew on right now. I'll have updated
performance results to submit later this week against the updated patch.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-28 16:29:54 Re: WIP: Deferrable unique constraints
Previous Message Tao Ma 2009-07-28 15:58:08 Re: question about the _SPI_save_plan() and plan cache