Re: Patch to show individual statement latencies in pgbench output - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch to show individual statement latencies in pgbench output
Date
Msg-id 3782.1281640803@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch to show individual statement latencies in pgbench output  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Patch to show individual statement latencies in pgbench output
List pgsql-hackers
Greg Smith <greg@2ndquadrant.com> writes:
> Florian Pflug wrote:
>> Attached is an updated version (v4).

> I've attached a v5.

BTW, I discovered a rather nasty shortcoming of this patch on platforms
without ENABLE_THREAD_SAFETY.  It doesn't work, and what's worse, it
*looks* like it's working, because it gives you plausible-looking
numbers.  But actually the numbers are only averages across the first
worker thread.  The other threads are in sub-processes where they can't
affect the contents of the parent's arrays.

Since platforms without ENABLE_THREAD_SAFETY are only a small minority
these days, this is probably not sufficient reason to reject the patch.
What I plan to do instead is reject the combination of -r with -j larger
than 1 on such platforms:
   if (is_latencies)   {       /*        * is_latencies only works with multiple threads in thread-based        *
implementations,not fork-based ones, because it supposes that the        * parent can see changes made to the command
datastructures by child        * threads.  It seems useful enough to accept despite this limitation,        * but
perhapswe should FIXME someday.        */
 
#ifndef ENABLE_THREAD_SAFETY       if (nthreads > 1)       {           fprintf(stderr, "-r does not work with -j larger
than1 on this platform.\n");           exit(1);       }
 
#endif

It could be fixed with enough effort, by having the child threads pass
back their numbers through the child-to-parent pipes.  I'm not
interested in doing that myself though.

If anyone thinks this problem makes it uncommittable, speak up now.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CommitFest 2010-07 week four progress report
Next
From: Robert Haas
Date:
Subject: Re: [ADMIN] postgres 9.0 crash when bringing up hot standby