Re: Some belated patch review for "Buffers" explain analyze patch - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Some belated patch review for "Buffers" explain analyze patch
Date
Msg-id 407d949e1002091557q3936cfb0l136033a9de2959e6@mail.gmail.com
Whole thread Raw
In response to Re: Some belated patch review for "Buffers" explain analyze patch  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Feb 9, 2010 at 10:42 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> A more important point is that it would be a nontrivial change, both as
>> to code and documentation, and it's too late for such in 9.0.  So what
>> we ought to be confining the discussion to right now is what 9.0 should
>> print here.
>
> It's exactly as nontrivial as the proposed change in the other direction.

I think it's non-triviality lies in the user-visible effects. Ie, we
won't have a release cycle of experience with the change ourselves to
see if we really like the new behaviour and can live with it.

I'm not sure where I stand myself as I find the averaging quite
confusing myself. I'm not sure how confusing it would be to change
though.

The total i/o done is likely to be something you want to compare with
some other metric like output from iostat or knowledge of how much
bandwidth your i/o system can provide so it does seem like totals are
relevant.

I think I'm leaning -- slightly -- towards calling out the discrepancy
by naming it something like "Total Buffer Usage:". But I could be
convinced otherwise.


--
greg


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Some belated patch review for "Buffers" explain analyze patch
Next
From: Andrew Chernow
Date:
Subject: Re: Listen / Notify - what to do when the queue is full