| From: | Andres Freund <andres(at)anarazel(dot)de> | 
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, 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-06-03 16:39:26 | 
| Message-ID: | 20160603163926.u6beiwx4kjzpfehj@alap3.anarazel.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2016-06-03 12:31:58 -0400, Robert Haas wrote:
> Now, what varies IME is how much total RAM there is in the system and
> how frequently they write that data, as opposed to reading it.  If
> they are on a tightly RAM-constrained system, then this situation
> won't arise because they won't be under the dirty background limit.
> And if they aren't writing that much data then they'll be fine too.
> But even putting all of that together I really don't see why you're
> trying to suggest that this is some bizarre set of circumstances that
> should only rarely happen in the real world.
I'm saying that if that happens constantly, you're better off adjusting
shared_buffers, because you're likely already suffering from latency
spikes and other issues. Optimizing for massive random write throughput
in a system that's not configured appropriately, at the cost of well
configured systems to suffer, doesn't seem like a good tradeoff to me.
Note that other operating systems like windows and freebsd *alreaddy*
write back much more aggressively (independent of this change). I seem
to recall you yourself being quite passionately arguing that the linux
behaviour around this is broken.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2016-06-03 16:50:46 | Re: array of domain types | 
| Previous Message | Nikolay Shaplov | 2016-06-03 16:33:38 | [DOC][PATCH]bloom index options limits |