On Thu, May 12, 2016 at 8:39 AM, Ashutosh Sharma <ashu.coe...@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-gcckryaqqtdu8kfe4n6h...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
