From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cost limited statements RFC |
Date: | 2013-06-10 21:43:17 |
Message-ID: | CA+TgmoaeD9TFewQzMOfNra6Xky0av2Jntaimj24NNxWXdUi27A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 8, 2013 at 10:00 PM, Greg Smith <greg(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-06-10 21:50:34 | Re: Batch API for After Triggers |
Previous Message | Peter Eisentraut | 2013-06-10 21:13:40 | Re: ALTER DEFAULT PRIVILEGES FOR ROLE is broken |