Re: EXPLAIN BUFFERS - Mailing list pgsql-hackers

From Robert Haas
Subject Re: EXPLAIN BUFFERS
Date
Msg-id 603c8f070912070624w7ce45c98mb6e3eb8f0b97c40e@mail.gmail.com
Whole thread Raw
In response to Re: EXPLAIN BUFFERS  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
On Mon, Dec 7, 2009 at 1:28 AM, Itagaki Takahiro
<itagaki.takahiro@oss.ntt.co.jp> wrote:
>> (ii) format: why does text output format have less counters than the other ones?
>
> That's because lines will be too long for text format. I think the
> three values in it are the most important and useful ones.

I disagree.  I objected to showing only part of the information when I
looked at this patch last CommitFest, and I object again now.  I do
*NOT* want to have to use JSON or XML to get at the counters you've
arbitrarily decided are not interesting to me.  I think with a little
creativity we can certainly get these into the text format, and I'm
willing to help with that.  In fact, if you want, I'll pick up this
patch and make it my first commit, though since you're now a committer
as well perhaps you'd prefer to do it yourself.

>> (v) accumulative: i don't remember if we discussed it but is there a reason
>> the number of buffers isn't accumulative? We already have cost and time that
>> are both accumulative. I saw BufferUsageAccumDiff() function but didn't try to
>> figure out why it isn't accumulating or passing the counters to parent nodes.
>
> It's reasonable. I'll change so if no objections.

+1 to change it.

...Robert


pgsql-hackers by date:

Previous
From: Xin Wang
Date:
Subject: How to cache a non-unique index?
Next
From: marcin mank
Date:
Subject: Re: bug: fuzzystrmatch levenshtein is wrong