On Wed, Jul 29, 2009 at 23:31, Josh Williams 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 development box
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 enco
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 informati
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 a
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 la
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
Itagaki Takahiro wrote:
> Greg Smith 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
Greg Smith 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 pg_pthread_t
#define
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 defi
On Jul 18, 2009, at 3:40 PM, Greg Stark wrote:
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haas
wrote:
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiro 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
a
On Sun, Jul 19, 2009 at 12:50 AM, Josh Berkus 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 pgsql-hackers mailing
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 (pgsql-hackers@postg
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haas wrote:
> On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
> Takahiro 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
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiro 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 via pgsql-hackers mailing list
Here is an updated version of multi-threaded pgbench patch.
Andrew Dunstan 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
without ENABLE_THREAD
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 goe
Andrew Dunstan 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, they seem to be just
Tom Lane wrote:
Andrew Dunstan 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 i
Andrew Dunstan 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 child processes, but I
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
Tom Lane wrote:
Alvaro Herrera 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 environment
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 wel
Alvaro Herrera 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 environments is not accep
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 e
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 h
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
