From: | Ants Aasma <ants(at)cybertec(dot)at> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: add timing of buffer I/O requests |
Date: | 2012-03-27 19:22:29 |
Message-ID: | CA+CSw_vP+r6vdS_Y0fs=ZYRxwTpDDyzNb8QuWokKi4hvSbD35A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 27, 2012 at 9:58 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I've committed the core of this. I left out the stats collector
> stuff, because it's still per-table and I think perhaps we should back
> off to just per-database. I changed it so that it does not conflate
> wait time with I/O time. Maybe there should be a separate method of
> measuring wait time, but I don't think it's a good idea for the
> per-backend stats to measure a different thing than what gets reported
> up to the stats collector - we should have ONE definition of each
> counter. I also tweaked the EXPLAIN output format a bit, and the
> docs.
Thank you for working on this.
Taking a fresh look at it, I agree with you that conflating waiting
for backend local IO, and IO performed by some other backend might
paint us into a corner. For most workloads the wait for IO performed
by others should be the minority anyway.
I won't really miss the per table stats. But if the pg_stat_statements
normalisation patch gets commited, it would be really neat to also
have IO waits there. It would be much easier to quickly diagnose "what
is causing all this IO" issues.
Thanks again,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-03-27 19:23:04 | Re: Patch: add timing of buffer I/O requests |
Previous Message | Alex | 2012-03-27 19:21:07 | Re: Another review of URI for libpq, v7 submission |