Hello Alik,
>> Your description is not very precise. What version of Postgres is used?
>> If there is a decline, compared to which version? Is there a link to
>> these results?
>
> Benchmark have been done in master v10. I am attaching image with results:
> .
Ok, thanks.
More precision would be helpful, such as the exact pgbench option used (eg
how many client per thread in pgbench, how long does it run, prepared
transactions, ...).
Intuitively, contention should explain a saturation of the tps
performance, because more clients are not effective to improve tps as the
wait for other clients, and the latency would degrade.
But it is unclear to me why the tps would be reduced even with lock
contention, so something seems amiss.
Performance debugging by mail is an uneasy task.
Maybe you could try zipf with unlogged tables, to check whether skipping
the WAL write does something.
Also Amit advice about the perf report looks useful.
>> Given the explanations, the random draw mostly hits values at the
>> beginning of the interval, so when the number of client goes higher one
>> just get locking contention on the updated row?
>
> Yes, exactly.
Ok. The uniform distribution run, if all other parameters are equal, gives
a hint about the potential performance when the performance bottleneck is
hit.
> On Workload A with uniform distribution PostgreSQL shows better results
> than MongoDB and MySQL(see attachment). Also you can notice that for
> small number of clients type of distribution does not affect on tps on
> MySQL.
Ok. I assume that you use pgbench for pg and other ad-hoc tools for the
other targets (mysql & mongodb).
--
Fabien.