Re: pgbench randomness initialization - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench randomness initialization
Date
Msg-id alpine.DEB.2.10.1604071609350.11001@sto
Whole thread Raw
In response to Re: pgbench randomness initialization  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgbench randomness initialization  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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.

Yep.

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.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Fujii Masao
Date:
Subject: Re: Support for N synchronous standby servers - take 2