On Thu, May 12, 2016 at 8:39 AM, Ashutosh Sharma <ashu.coek88@gmail.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