Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group