On Sat, Jun 8, 2013 at 10:00 PM, Greg Smith <g...@2ndquadrant.com> wrote: >> But I have neither any firsthand experience nor any >> empirical reason to presume that the write limit needs to be lower >> when the read-rate is high. > > No argument from me that that this is an uncommon issue. Before getting > into an example, I should highlight this is only an efficiency issue to me. > If I can't blend the two rates together, what I'll have to do is set both > read and write individually to lower values than I can right now. That's > not terrible; I don't actually have a problem with that form of UI > refactoring. I just need separate read and write limits of *some* form. If > everyone thinks it's cleaner to give two direct limit knobs and eliminate > the concept of multipliers and coupling, that's a reasonable refactoring. > It just isn't the easiest change from what's there now, and that's what I > was trying to push through before.
OK, understood. Let's see what others have to say. > On the throughput graph, + values above the axis are write throughput, while > - ones are reads. It's subtle, but during the periods where the writes are > heavy, the read I/O the server can support to the same drive drops too. > Compare 6:00 (low writes, high reads) to 12:00 (high writes, low reads). > When writes rise, it can't quite support the same read throughput anymore. > This isn't that surprising on a system where reads cost more than writes do. That is indeed quite a surprising system, but I'm having trouble seeing the effect you're referring to, because it looks to me like a lot of the read peaks correspond to write peaks. -- 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