Re: EXPLAIN BUFFERS

Euler Taveira de Oliveira <euler(at)timbira(dot)com> wrote:

> I'm looking at your patch now... It is almost there but has some issues.
>
> (i) documentation: you have more than three counters and they could be
> mentioned in docs too.

I'll add documentation for all variables.

> (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.

> (iii) string: i don't like the string in text format
> (1) it is not concise (only the first item has the word 'Blocks'),
> (2) what block is it about? Shared, Local, or Temp?

The format was suggested here and no objections then.
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00268.php
I think the current output is enough and useful in normal use.
We can use XML or JSON format for more details.

I think
Blocks Hit: 1641 Read: 0 Temp Read: 1443
means
Blocks (Hit: 1641 Read: 0 Temp Read: 1443)
i.e., Blocks of hit, blocks of reads, and Blocks of temp reads.

> (3) why don't you include the other ones?, and
> (4) why don't you include the written counters?
> (iv) text format: i don't have a good suggestion but here are some ideas. The
> former is too long and the latter is too verbose.

Their reasons are the same as (ii).

> (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.

> (vi) comment: the 'at start' is superfluous. Please, remove it.

Ooops, I'll remove them.

> (vii) all nodes: I'm thinking if we need this information in all nodes (even
> in those nodes that don't read or write). It would be less verbose but it
> could complicate some parser's life. Of course, if we suppress this
> information, we need to include it on the top node even if we don't read or
> write in it.

I cannot understand what you mean -- should I suppress the lines when they
have all-zero values?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center