Re: pgbench randomness initialization

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench randomness initialization
Date: 2016-04-07 14:26:43
Message-ID: alpine.DEB.2.10.1604071609350.11001@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>> It means that you can't separate between OS caused, and pgbench order
>> caused performance differences.
> I'm not objecting to adding an option for this; but I think Fabien is
> right that it shouldn't be the default.


Andres, attached is a simple POC with an option & environment variable
(whereas I should rather have looked at the current checkpointer/vacuum
issue which I have reproduced:-().

While testing it I had a funny pattern, something like:

pgbench --random-seed=123 -M prepared -T 3 -P 1 -S
1.0: 600 tps
2.0: 600 tps
3.0: 600 tps

First rerun just after:

pgbench --random-seed=123 -M prepared -T 3 -P 1 -S
1.0: 1800 tps
2.0: 600 tps
3.0: 600 tps

The first rerun hits the same pages, so the first 1800 transactions are
run in one second, and then it is new pages which are loaded so the
performance goes down.

Second rerun just after:

pgbench --random-seed=123 -M prepared -T 3 -P 1 -S
1.0: 1800 tps
2.0: 1400 tps
3.0: 600 tps

The second redun hits the same 3000 transactions than the previous one in
about 1.7 seconds, then goes back to 600 tps for new pages...

After more iterations the performance is 1800 tps during the 3 seconds.

This clearly illustrates that it should be used with caution.


Attachment Content-Type Size
pgbench-seed-1.patch text/x-diff 3.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2016-04-07 14:43:57 Re: Support for N synchronous standby servers - take 2
Previous Message Robert Haas 2016-04-07 13:55:41 Re: Using quicksort for every external sort run