From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench randomness initialization |
Date: | 2016-04-07 13:33:05 |
Message-ID: | CA+TgmoZ8Ds5SDu2A48nHnaJ+4y9o0-qFfgvbxjovDUOszW-GbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 7, 2016 at 9:15 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> It's not about "covering it up"; it's about actually being able to take
> action based on benchmark results, and about practically being able to
> run benchmarks. The argument above means essentially that we need to run
> a significant number of pgbench runs for *anything*, because running
> them 3-5 times before/after just isn't meaningful enough.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-07 13:35:32 | Re: Truncating/vacuuming relations on full tablespaces |
Previous Message | Andres Freund | 2016-04-07 13:18:04 | Re: Speed up Clog Access by increasing CLOG buffers |