Hi,
On 2015-08-07 19:30:46 +0200, Andres Freund wrote:
> On 2015-08-07 12:49:20 -0400, Jesper Pedersen wrote:
> > No, this patch helps on performance - there is an improvement in numbers
> > between
> >
> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=253de7e1eb9abbcf57e6c229a8a38abd6455c7de
> >
> > and
> >
> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0e141c0fbb211bdd23783afa731e3eef95c9ad7a
> >
> > but you will have to use a 9.5 pgbench to see it, especially with higher
> > client counts.
Hm, you were using -P X, is that right?
> This bisects down to 1bc90f7a7b7441a88e2c6d4a0e9b6f9c1499ad30 - "Remove
> thread-emulation support from pgbench."
And the apparent reason seems to be that too much code has been removed
in that commit:
@@ -3650,11 +3631,7 @@ threadRun(void *arg) } /* also wake up to print the next progress report on time */
- if (progress && min_usec > 0
-#if !defined(PTHREAD_FORK_EMULATION)
- && thread->tid == 0
-#endif /* !PTHREAD_FORK_EMULATION */
- )
+ if (progress && min_usec > 0) { /* get current time if needed */ if (now_usec == 0)
@@ -3710,7 +3687,7 @@ threadRun(void *arg)
This causes all threads but thread 0 (i.e. the primary process) to busy
loop around select: min_usec will be set to 0 once the first progress
report interval has been reached: if (now_usec >= next_report) min_usec = 0; else if
((next_report- now_usec) < min_usec) min_usec = next_report - now_usec;
but since we never actually print the progress interval in any thread
but the the main process that's always true from then on:
/* progress report by thread 0 for all threads */ if (progress && thread->tid == 0) {
... /* * Ensure that the next report is in the future, in case * pgbench/postgres
gotstuck somewhere. */ do { next_report += (int64) progress *1000000;
} while (now >= next_report);
Hrmpf.
Andres
