| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, 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 15:50:22 |
| Message-ID: | 20160512155022.roiss6nqisxxqex6@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-05-12 11:27:31 -0400, Robert Haas wrote:
> On Thu, May 12, 2016 at 11:13 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Could you run this one with a number of different backend_flush_after
> > settings? I'm suspsecting the primary issue is that the default is too low.
>
> What values do you think would be good to test? Maybe provide 3 or 4
> suggested values to try?
0 (disabled), 16 (current default), 32, 64, 128, 256?
I'm suspecting that only backend_flush_after_* has these negative
performance implications at this point. One path is to increase that
option's default value, another is to disable only backend guided
flushing. And add a strong hint that if you care about predictable
throughput you might want to enable it.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-05-12 15:56:28 | Re: Change error code for hstore syntax error |
| Previous Message | Tom Lane | 2016-05-12 15:48:26 | Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) |