Re: Patch: add timing of buffer I/O requests

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

In response to

Responses

Browse pgsql-hackers by date

  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