Re: PGBench on Windows - connections are subprocesses? - Mailing list pgsql-general

From Durumdara
Subject Re: PGBench on Windows - connections are subprocesses?
Date
Msg-id CAEcMXhkZCZtj3nsT1d4KVD6w0XZ3qEOULaYozOSwzFAm0tVcUg@mail.gmail.com
Whole thread Raw
In response to Re: PGBench on Windows - connections are subprocesses?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Dear Tom!

Tom Lane <tgl@sss.pgh.pa.us> ezt írta (időpont: 2020. júl. 20., H, 15:38):

There are -j threads in the pgbench process, and -c connections to
the server (hence -c backend processes on the server side).  Each
of the pgbench threads is responsible for sending queries to a subset
of the connections.  Setting -j more than -c is useless (I forget
if it's actually an error).  If you set -j to, say, half of -c then
each thread has exactly two connections to manage.  If -j is too
small compared to -c then pgbench itself tends to become the bottleneck.

Without -j, we have N connections, but one thread.
So this thread serves all of the connections one by one? The 1. and 2. and 3. connection while others do nothing (standing by)?
Or like Round Robin: a job from C1, next job from C2, .... job from CN - then job from C1.... and no more jobs?

And if J = C means realtime parallel test?
Because each thread has only one connection, and they work concurrently as real users do?

Then if I want to simulate 500 users heavy work, I need to set J=C=500?

Thank you for the information!

BW
   DD


 

pgsql-general by date:

Previous
From: Durumdara
Date:
Subject: Re: PGBench on Windows - connections are subprocesses?
Next
From: Thomas Kellerer
Date:
Subject: Re: Logical replication from 11.x to 12.x and "unique key violations"