On Thu, Mar 21, 2019 at 2:18 AM Haribabu Kommi <kommi.harib...@gmail.com> wrote: > With Inclusion of parallel worker transactions, the TPS will be a higher > number, > thus user may find it as better throughput. This is the case with one of our > tool. > The tool changes the configuration randomly to find out the best configuration > for the server based on a set of workload, during our test, with some > configurations, > the TPS is so good, but the overall performance is slow as the system is > having > less resources to keep up with that configuration. > > Opinions?
Well, I think that might be a sign that the data isn't being used correctly. I don't have a strong position on what the "right" thing to do here is, but I think if you want to know how many client transactions are being executed, you should count them on the client side, as pgbench does. I agree that it's a little funny to count the parallel worker commit as a separate transaction, since in a certain sense it is part of the same transaction. But if you do that, then as already noted you have to next decide what to do about other transactions that parallel workers use internally. And then you have to decide what to do about other background transactions. And there's not really one "right" answer to any of these questions, I don't think. You might want to count different things depending on how the information is going to be used. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
