Re: pgbench - exclude pthread_create() from connection start timing

From: Noah Misch <noah(at)leadboat(dot)com>
To: Fabien COELHO <fabien(dot)coelho(at)mines-paristech(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, pavel(dot)stehule(at)gmail(dot)com
Subject: Re: pgbench - exclude pthread_create() from connection start timing
Date: 2013-10-05 23:14:15
Message-ID: 20131005231415.GC180956@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 01, 2013 at 02:50:29PM +0200, Fabien COELHO wrote:
> I do not think that there is a clean and simple way to take the
> start/stop period into account when computing global performances of
> a run. The TPC-C benchmark tells to ignore the warmup/closure
> period, whatever they are, and only perform measures within the
> steady state. However the full graph must be provided when the bench
> is provided.

That makes sense to me. "pgbench --progress" and "pgbench --log
--aggregate-interval" are good tools for excluding non-steady-state periods.

> About better measures: If I could rely on having threads, I would
> simply synchronise the threads at the beginning so that they
> actually start after they are all created, and one thread would
> decide when to stop and set a shared volatile variable to stop all
> transactions more or less at once. In this case, the thread start
> time would be taken just after the synchronization, and maybe only
> by thread 0 would be enough.
>
> Note that this is pretty standard stuff with threads, ISTM that it
> would solve most of the issues, *but* this is not possible with the
> "thread fork emulation" implemented by pgbench, which really means
> no threads at all.

You could do those same things in the fork emulation mode using anonymous
shared memory, like we do in the server. That would permit removing the
current "#ifdef PTHREAD_FORK_EMULATION" wart, too.

For the time being, I propose the attached comment patch.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

Attachment Content-Type Size
pgbench-thread-timing-model-comment-v1.patch text/plain 1014 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2013-10-05 23:58:25 Re: GIN improvements part 1: additional information
Previous Message Marko Tiikkaja 2013-10-05 22:15:45 Re: plpgsql.print_strict_params