- the tps is global, with a mutex to share the global stochastic process
  - there is an adaptation for the "fork" emulation
  - I do not know wheter this works with Win32 pthread stuff.

Instead of this complexity,

Well, the mutex impact is very localized in the code. The complexity is more linked to the three "thread" implementations intermixed there.

can we just split the TPS input per client?

Obviously it is possible. Note that it is more logical to do that per thread. I did one shared stochastic process because it makes more sense to have just one.

That's all I was thinking of here, not adding a new set of threading issues. If 10000 TPS is requested and there's 10 clients, just set the delay so that each of them targets 1000 TPS.

Ok, so I understand that a mutex is too much!

I'm guessing it's more accurate to have them all communicate as you've done here, but it seems like a whole class of new bugs and potential bottlenecks could come out of that.

I do not think that there is a performance or locking contension issue: it is about getting a mutex for a section which performs one integer add and two integer assignements, that is about 3 instructions, to be compared with the task of performing database operations over the network. There are several orders of magnitudes between those tasks. It would need a more than terrible mutex implementation to have any significant impact.

Whenever someone touches the threading model for pgbench it usually gives a stack of build farm headaches. Better to avoid those unless there's really a compelling reason to go through that.

I agree that the threading model in pgbench is a mess, mostly because of the 3 concurrent implementations intermixed in the code. Getting rid of the fork emulation and win32 special handling and only keeping the pthread implementation, which seems to be available even on windows, would be a relief. I'm not sure if there is still a rationale to have these 3 implementations, but it ensures a maintenance mess:-(

I'll submit a version without mutex, but ISTM that this one is conceptually cleaner, although I'm not sure about what happens on windows.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to