Re: Perf Benchmarking and regression.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Perf Benchmarking and regression.
Date: 2016-05-12 14:49:06
Message-ID: CA+Tgmoav03TPq9-vWB5B4rY=iFrTc5bc_E8=ayVbCf=Aun1fSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 12, 2016 at 8:39 AM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> Please find the test results for the following set of combinations taken at
> 128 client counts:
>
> 1) Unpatched master, default *_flush_after : TPS = 10925.882396
>
> 2) Unpatched master, *_flush_after=0 : TPS = 18613.343529
>
> 3) That line removed with #if 0, default *_flush_after : TPS = 9856.809278
>
> 4) That line removed with #if 0, *_flush_after=0 : TPS = 18158.648023

I'm getting increasingly unhappy about the checkpoint flush control.
I saw major regressions on my parallel COPY test, too:

http://www.postgresql.org/message-id/CA+TgmoYoUQf9cGcpgyGNgZQHcY-gCcKRyAqQtDU8KFE4N6HVkA@mail.gmail.com

That was a completely different machine (POWER7 instead of Intel,
lousy disks instead of good ones) and a completely different workload.
Considering these results, I think there's now plenty of evidence to
suggest that this feature is going to be horrible for a large number
of users. A 45% regression on pgbench is horrible. (Nobody wants to
take even a 1% hit for snapshot too old, right?) Sure, it might not
be that way for every user on every Linux system, and I'm sure it
performed well on the systems where Andres benchmarked it, or he
wouldn't have committed it. But our goal can't be to run well only on
the newest hardware with the least-buggy kernel...

> Here, That line points to "AddWaitEventToSet(FeBeWaitSet,
> WL_POSTMASTER_DEATH, -1, NULL, NULL); in pq_init()."

Given the above results, it's not clear whether that is making things
better or worse.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-05-12 15:13:25 Re: Perf Benchmarking and regression.
Previous Message Kevin Grittner 2016-05-12 14:25:57 Re: Incremental refresh of materialized view - Patch