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 got stuck somewhere. */ do { next_report += (int64) progress *1000000; } while (now >= next_report); Hrmpf. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers