Thread: PATCH: pgbench - remove thread fork-emulation

PATCH: pgbench - remove thread fork-emulation

From
Fabien COELHO
Date:
This patch removes the pgbench thread fork-emulation code and simplifies 
things where possible, especially around pthread_create and pthread_join. 
The stats collection for the report is done directly instead of using an 
intermediate structure.

As a result, if no thread implementation is available, pgbench is 
restricted to work with only the main thread (ie "pgbench -j 1 ...").


== Rational ==

Pgbench currently provides a thread emulation through process forks. This 
feature was developed way back when it may have been common that some 
platforms were not supporting threads. This is now very rare (can you name 
one such platform?).

However, the thread fork-emulation feature has drawbacks: Namely, 
processes are not threads, the memory is not shared (sure), so it hinders 
simple implementation for some features, or results in not providing these 
features with fork-emulation, or having a different behavior under 
fork-emulation:

Latency collection (-r) is not supported with fork emulation.

Progress (-P) is reported differently with fork emulation.

For a new feature under discussion, which consist in allowing one log 
instead of per-thread logs, supporting fork-emulation requires a (heavy) 
post-processing external sort phase whereas with actual threads all 
threads can share and append to the same log file with limited overhead, 
which is significantly simpler.

== Note ==

This is a small regression (for platforms without thread support, -j J 
with J > 1 is not supported anymore after the patch), so maybe this should 
be included for PostgreSQL 10.0 only? I do not think this should required, 
but this is only my opinion.

-- 
Fabien.

Re: PATCH: pgbench - remove thread fork-emulation

From
Heikki Linnakangas
Date:
On 04/28/2015 02:18 AM, Fabien COELHO wrote:
> This patch removes the pgbench thread fork-emulation code and simplifies
> things where possible, especially around pthread_create and pthread_join.
> The stats collection for the report is done directly instead of using an
> intermediate structure.
>
> As a result, if no thread implementation is available, pgbench is
> restricted to work with only the main thread (ie "pgbench -j 1 ...").
>
>
> == Rational ==
>
> Pgbench currently provides a thread emulation through process forks. This
> feature was developed way back when it may have been common that some
> platforms were not supporting threads. This is now very rare (can you name
> one such platform?).
>
> However, the thread fork-emulation feature has drawbacks: Namely,
> processes are not threads, the memory is not shared (sure), so it hinders
> simple implementation for some features, or results in not providing these
> features with fork-emulation, or having a different behavior under
> fork-emulation:
>
> Latency collection (-r) is not supported with fork emulation.
>
> Progress (-P) is reported differently with fork emulation.
>
> For a new feature under discussion, which consist in allowing one log
> instead of per-thread logs, supporting fork-emulation requires a (heavy)
> post-processing external sort phase whereas with actual threads all
> threads can share and append to the same log file with limited overhead,
> which is significantly simpler.

I agree with all that, it's time to let the fork-emulation mode to go. 
Committed.

- Heikki