On Wed, Jul 29, 2009 at 23:31, Josh Williamsjoshwilli...@ij.net wrote:
On Tue, 2009-07-28 at 23:38 -0400, Josh Williams wrote:
Huh, running the patched version on a single thread with 128 clients
just got it to crash. Actually consistently, three times now. Will try
the same thing on the
On Tue, 2009-07-28 at 23:38 -0400, Josh Williams wrote:
Huh, running the patched version on a single thread with 128 clients
just got it to crash. Actually consistently, three times now. Will try
the same thing on the development box tomorrow morning to get some
better debugging information.
This patch is wrapping up nicely. I re-tested against the updated
pgbench-mt_20090724 and now I get similar results whether or not
--enable-thread-safety is enabled on Linux, so that problem is gone.
Josh's successful Windows tests along with finding the bug he attached a
patch to is also
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
On Tue, 2009-07-28 at 12:10 -0400, Greg Smith wrote:
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
On Wed, 2009-07-22 at 22:23 -0400, Greg Smith wrote:
Onto performance. My test system has a 16 cores of Xeon X5550 @
2.67GHz.
I created a little pgbench database (-s 10) and used the default
postgresql.conf parameters for everything but max_connections for a
rough
initial test.
To test
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
Greg Smith gsm...@gregsmith.com wrote:
That second code path, when --enable-thread-safety is turned off, crashes
and burns on my Linux system:
It comes from confliction of identifiers.
Renaming identifiers with #define can solve
I just took multi-threaded pgbench for an initial spin, looks good overall
with only a couple of small rough edges.
The latest code works differently depending on whether you compiled with
--enable-thread-safety or not, it defines some structures based on fork if
it's not enabled:
#elif
Greg Smith gsm...@gregsmith.com wrote:
That second code path, when --enable-thread-safety is turned off, crashes
and burns on my Linux system:
It comes from confliction of identifiers.
Renaming identifiers with #define can solve the errors:
#define pthread_t
On Sun, Jul 19, 2009 at 12:50 AM, Josh Berkusj...@agliodbs.com wrote:
Greg (Smith), do you have time to review this version? If not, I will
assign a round-robin reviewer when one becomes available.
I can do a concurrency test of this next week.
Sounds good.
...Robert
--
Sent via
On Jul 18, 2009, at 3:40 PM, Greg Stark gsst...@mit.edu wrote:
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haasrobertmh...@gmail.com
wrote:
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of multi-threaded pgbench patch.
Greg
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of multi-threaded pgbench patch.
Greg (Smith), do you have time to review this version? If not, I will
assign a round-robin reviewer when one becomes available.
...Robert
--
Sent
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haasrobertmh...@gmail.com wrote:
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated version of multi-threaded pgbench patch.
Greg (Smith), do you have time to review this version? If not, I will
Greg (Smith), do you have time to review this version? If not, I will
assign a round-robin reviewer when one becomes available.
I can do a concurrency test of this next week.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
Here is an updated version of multi-threaded pgbench patch.
Andrew Dunstan and...@dunslane.net wrote:
Hmm, but how will you communicate stats back from the sub-processes?
My first reaction is to say use a pipe.
I added partial implementation of pthread using fork and pipe for platform
Itagaki Takahiro wrote:
Is it acceptable to use pthread in contrib module?
We don't have a precedent it seems. I think the requirement would be
that it should compile if pthread support is not present.
If ok, I will add the patch to the next commitfest.
Add it anyway -- discussion should
Alvaro Herrera wrote:
Itagaki Takahiro wrote:
Is it acceptable to use pthread in contrib module?
We don't have a precedent it seems. I think the requirement would be
that it should compile if pthread support is not present.
My thoughts as well. But I wonder, would it be harder or easier
Alvaro Herrera alvhe...@commandprompt.com writes:
Itagaki Takahiro wrote:
Is it acceptable to use pthread in contrib module?
We don't have a precedent it seems. I think the requirement would be
that it should compile if pthread support is not present.
Right. Breaking it for non-pthread
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Itagaki Takahiro wrote:
Is it acceptable to use pthread in contrib module?
We don't have a precedent it seems. I think the requirement would be
that it should compile if pthread support is not present.
My thoughts as
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Itagaki Takahiro wrote:
Is it acceptable to use pthread in contrib module?
We don't have a precedent it seems. I think the requirement would be
that it should compile if pthread support is not present.
Right. Breaking it
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
Andrew Dunstan and...@dunslane.net writes:
I think you should have it use pthreads if available, or Windows threads
there, or fork() elsewhere.
Hmm, but how will you communicate stats back from the sub-processes?
pg_restore doesn't need anything more than a success/failure result
from its
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I think you should have it use pthreads if available, or Windows threads
there, or fork() elsewhere.
Hmm, but how will you communicate stats back from the sub-processes?
pg_restore doesn't need anything more than a
Andrew Dunstan and...@dunslane.net wrote:
I think you should have it use pthreads if available, or Windows threads
there, or fork() elsewhere.
Just a question - which platform does not support any threading?
I think threading is very common in modern applications. If there
are such OSes,
On Wed, 8 Jul 2009, Tom Lane wrote:
pg_restore doesn't need anything more than a success/failure result
from its child processes, but I think pgbench will want more.
The biggest chunk of returned state to consider is how each client
transaction generates a line of latency information that
Pgbench is a famous tool to measure postgres performance, but nowadays
it does not work well because it cannot use multiple CPUs. On the other
hand, postgres server can use CPUs very well, so the bottle-neck of
workload is *in pgbench*.
Multi-threading would be a solution. The attached patch adds
26 matches
Mail list logo
