Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

On Thu, Mar 21, 2019 at 2:18 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)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