| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cost limited statements RFC |
| Date: | 2013-05-24 19:11:12 |
| Message-ID: | CA+TgmoYckMxW4+mzx8bEiVBBCMPqWMG-dJ9dewG3qBAyU2nPbw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 24, 2013 at 10:36 AM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> Doesn't that hit the old issue of not knowing if a read came from FS cache
> or disk? I realize that the current cost_delay mechanism suffers from that
> too, but since the API is lower level that restriction is much more
> apparent.
Sure, but I think it's still useful despite that limitation.
> Instead of KB/s, could we look at how much time one process is spending
> waiting on IO vs the rest of the cluster? Is it reasonable for us to measure
> IO wait time for every request, at least on the most popular OSes?
I doubt that's going to be very meaningful. The backend that dirties
the buffer is fairly likely to be different from the backend that
writes it out.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2013-05-24 19:14:33 | Re: adding import in pl/python function |
| Previous Message | Szymon Guz | 2013-05-24 19:10:26 | adding import in pl/python function |