PATCH: pgbench - remove thread fork-emulation - Mailing list pgsql-hackers

From Fabien COELHO
Subject PATCH: pgbench - remove thread fork-emulation
Date
Msg-id alpine.DEB.2.10.1504271910200.13807@sto
Whole thread Raw
Responses Re: PATCH: pgbench - remove thread fork-emulation
List pgsql-hackers
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.

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT syntax issues
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT syntax issues