On Tue, Feb 16, 2010 at 2:48 AM, Robert Haas robertmh...@gmail.com wrote:
Multiplying by the block size makes it sound as if all the
memory was read or used, which is simply not the case - especially for
things like buffer hits, which don't actually read or allocate any
memory at all.
In
Greg Stark escribió:
On Tue, Feb 16, 2010 at 2:48 AM, Robert Haas robertmh...@gmail.com wrote:
Upon further review, I also notice that this patch seems to have
falsified the EXPLAIN documentation - both the description of the
BUFFERS option and the description of the FORMAT option are no
Alvaro Herrera alvhe...@commandprompt.com writes:
Greg Stark escribió:
Oops. Well, I would like to know if I'm in the minority and have to
roll this back before I fix that.
My personal opinion is that displaying number of blocks in all EXPLAIN
formats is more consistent.
FWIW, I vote for
On Tue, Feb 16, 2010 at 3:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Greg Stark escribió:
Oops. Well, I would like to know if I'm in the minority and have to
roll this back before I fix that.
My personal opinion is that displaying number of
On Sun, Feb 14, 2010 at 8:25 PM, Greg Stark st...@mit.edu wrote:
So this is what I did about my two complaints earlier about the
explain buffer patch.
a) Changed the line description to Total Buffer Usage which at least
hints that it's something more akin to the Total runtime listed at
the
On Mon, Feb 15, 2010 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote:
a) Changed the line description to Total Buffer Usage which at least
hints that it's something more akin to the Total runtime listed at
the bottom than the actual time.
b) Used units of memory -- I formatted them with 3
Greg Stark wrote:
We can always continue tweak the details of the format such as adding
spaces before the units to make it similar to the pg_size_pretty().
I'm not sure I like the idea of making it exactly equivalent because
pg_size_pretty() doesn't print any decimals so it's pretty imprecise
On Mon, Feb 15, 2010 at 9:55 AM, Greg Stark st...@mit.edu wrote:
On Mon, Feb 15, 2010 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote:
a) Changed the line description to Total Buffer Usage which at least
hints that it's something more akin to the Total runtime listed at
the bottom than the
On Mon, Feb 15, 2010 at 6:05 PM, Robert Haas robertmh...@gmail.com wrote:
Well there was a 30+ message thread almost a week ago where there
seemed to be some contention over the issue of whether the numbers
should be averages or totals. But were there was no dispute over the
idea of printing
On Mon, Feb 15, 2010 at 1:29 PM, Greg Stark st...@mit.edu wrote:
On Mon, Feb 15, 2010 at 6:05 PM, Robert Haas robertmh...@gmail.com wrote:
Well there was a 30+ message thread almost a week ago where there
seemed to be some contention over the issue of whether the numbers
should be averages or
On Mon, Feb 15, 2010 at 7:58 PM, Robert Haas robertmh...@gmail.com wrote:
To me, buffers seem like discrete (and unitless)
entities, and we handle them that way elsewhere in the system (see,
e.g. pg_stat_database, pg_statio_all_tables). I don't know that it's
a good idea to display that same
Greg Stark wrote:
We do *not* display raw block numbers anywhere else. Generally I think
we should have a policy of outputing human-readable standard units of
memory whenever displaying a memory quantity. Actually I thought we
already had that policy, hence things like...
The first counter
On Mon, Feb 15, 2010 at 6:44 PM, Greg Stark st...@mit.edu wrote:
I did respond to it. The whole point is that the text output is for a
human to read. It should be printed in human-readable units. Not some
arbitrary internal unit of accounting that they then have to do
arithmetic on to make
So this is what I did about my two complaints earlier about the
explain buffer patch.
a) Changed the line description to Total Buffer Usage which at least
hints that it's something more akin to the Total runtime listed at
the bottom than the actual time.
b) Used units of memory -- I formatted
Greg Stark wrote:
b) Used units of memory -- I formatted them with 3 significant digits
(unless the unit is bytes or kB where that would be silly). It's just
what looked best to my eye.
How does this compare with what comes out of pg_size_pretty
(src/backend/utils/adt/dbsize.c)? I already
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Pushing extra arguments around would create overhead of its own ...
overhead that would be paid even when not using EXPLAIN at all.
I cannot understand what you mean... The additional argument should
On Sun, Dec 13, 2009 at 11:49 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
The attached patch [...]
Committed.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas robertmh...@gmail.com wrote:
OK, done, see attached. I also noticed when looking through this that
the documentation says that auto_explain.log_buffers is ignored unless
auto_explain.log_analyze is set. That is true and seems right to me,
but for some reason
On Sun, Dec 13, 2009 at 7:55 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
OK, done, see attached. I also noticed when looking through this that
the documentation says that auto_explain.log_buffers is ignored unless
Robert Haas robertmh...@gmail.com wrote:
I have a question about the comment in InstrStopNode(), which reads:
Adds delta of buffer usage to node's count and resets counter to
start so that the counters are not double counted by parent nodes.
It then calls BufferUsageAccumDiff(), but that
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Should I add countBufferUsage boolean arguments to all places
doInstrument booleans are currently used? This requires several
minor modifications of codes in many places.
Pushing extra arguments around would create overhead of its own ...
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Should I add countBufferUsage boolean arguments to all places
doInstrument booleans are currently used? This requires several
minor modifications of codes in many places.
Pushing extra arguments
On Sun, Dec 13, 2009 at 10:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Should I add countBufferUsage boolean arguments to all places
doInstrument booleans are currently used? This requires several
minor modifications of codes in many
On Sun, Dec 13, 2009 at 10:00 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Two other thoughts:
1. It doesn't appear that there is any provision to ever zero
pgBufferUsage. Shouldn't we do this, say, once per explain, just to
avoid the possibility of overflowing the counters?
Robert Haas robertmh...@gmail.com wrote:
Well, I think we need to do something. I don't really want to tack
another 5-6% overhead onto EXPLAIN ANALYZE. Maybe we could recast the
doInstrument argument as a set of OR'd flags?
I'm thinking the same thing (OR'd flags) right now.
The attached
On Sun, Dec 13, 2009 at 11:49 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
Well, I think we need to do something. I don't really want to tack
another 5-6% overhead onto EXPLAIN ANALYZE. Maybe we could recast the
doInstrument argument
Robert Haas escreveu:
On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Anyway, a revised patch according to the comments is attached.
The new text format is:
Buffers: shared hit=675 read=968, temp read=1443 written=1443
* Zero values are omitted.
On Fri, Dec 11, 2009 at 11:36 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Robert Haas escreveu:
On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Anyway, a revised patch according to the comments is attached.
The new text format is:
Buffers:
Robert Haas escreveu:
I'm not sure whether this is a good idea or not. Let me read the
patch. I'm not sure an EXPLAIN option is really an adequate
substitute for log_statement_stats - the latter will let you get stats
for all of your queries automatically, I believe, and might still be
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Robert Haas escreveu:
I'm not sure whether this is a good idea or not. Let me read the
patch. I'm not sure an EXPLAIN option is really an adequate
substitute for log_statement_stats - the latter will let you
Takahiro Itagaki escribió:
=# EXPLAIN (BUFFERS, ANALYZE) SELECT *
FROM pgbench_accounts a, pgbench_branches b
WHERE a.bid = b.bid AND abalance 0 ORDER BY abalance;
QUERY PLAN
Alvaro Herrera alvhe...@commandprompt.com writes:
Takahiro Itagaki escribió:
Blocks: (shared hit=96 read=1544 written=0) (local hit=0 read=0 written=0)
(temp read=0 written=0)
Maybe I missed part of this discussion, but it seems a bit weird to have
an option named buffers turn on a line
On Thu, Dec 10, 2009 at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Takahiro Itagaki escribió:
Blocks: (shared hit=96 read=1544 written=0) (local hit=0 read=0 written=0)
(temp read=0 written=0)
Maybe I missed part of this discussion, but it
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Why? If you want this information for all of your queries, you can always set
auto_explain.log_min_duration to 0. But if you're suggesting that we should
maintain
Robert Haas wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both places.
I don't know how blocks got into here in the first place--this concept
is buffers just
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both places.
I don't know how
On Thu, Dec 10, 2009 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Why? If you want this information for all of your queries, you can always
set
Robert Haas escreveu:
The only reason anyone is even thinking that they need parentheses
here is because they're trying to put three separate groups of
buffer-related statistics - a total of 8 values - on the same output
line. If this were split up over three output lines, no one would
even
Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith g...@2ndquadrant.com wrote:
I don't think IO is a terrible name for an option but I like BUFFERS
better. ?I don't think the BUFFERS/BLOCKS confusion is too bad, but
perhaps we could use BUFFERS in both
On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Anyway, a revised patch according to the comments is attached.
The new text format is:
Buffers: shared hit=675 read=968, temp read=1443 written=1443
* Zero values are omitted. (Non-text formats could
Takahiro Itagaki escreveu:
Sure, I should have merge all of the comments. Patch attached.
Thanks for your effort. Looks sane to me.
- Updated the output format as follows. I think this format is the most
similar to existing lines. (actual by ANALYZE and Filter:).
If people object to it,
On Wed, Dec 9, 2009 at 12:36 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Note that the patch also removes buffer counters from log_statement_stats,
but we only have brief descriptions about the options. Our documentation
say nothing about buffer counters, so I didn't modify those
On Dec 8, 2009, at 12:05 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
I could live with the equals signs, but the use of parentheses seems
weird and inconsistent with normal english usage (which permits
parentheses as a means of making parenthetical comments).
But it is
Euler Taveira de Oliveira wrote:
If there is no more objections, I'll flag the patch 'ready for committer'
I just executed that. Note that there are two bits of subjective
tweaking possible to do with this one when it's committed: slimming
down the width of the display, and Euler's
Greg Smith g...@2ndquadrant.com wrote:
I just executed that. Note that there are two bits of subjective
tweaking possible to do with this one when it's committed: slimming
down the width of the display, and Euler's suggestion's for rewording.
I linked to both of those messages in the
On Mon, Dec 7, 2009 at 1:28 AM, Itagaki Takahiro
itagaki.takah...@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
Itagaki Takahiro escreveu:
I think the current output is enough and useful in normal use.
We can use XML or JSON format for more details.
I don't think it is a good idea to have different information in different
formats. I'm with Robert; *don't* do that. If you want to suppress the other
ones
Here is an updated patch per discussion.
* Counters are accumulative. They contain I/Os by child nodes.
* Text format shows all counters.
* Add shared_ prefix to variables representing shared buffers/blocks.
Euler Taveira de Oliveira eu...@timbira.com wrote:
Itagaki Takahiro escreveu:
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is an updated patch per discussion.
* Counters are accumulative. They contain I/Os by child nodes.
* Text format shows all counters.
* Add shared_ prefix to variables representing shared
Robert Haas wrote:
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Obviously I should not hide any information only in the text format.
The new output will be: (in one line)
Shared Blocks: (hit=2 read=1641 written=0) Local Blocks: (hit=0 read=0
On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Obviously I should not hide any information only in the text format.
The new output will be: (in one line)
Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith g...@2ndquadrant.com wrote:
(1) Blocks Shared: (hit=2 read=1641 written=0) Local: (hit=0 read=0
written=0) Temp: (read=1443 written=1443)
I could live with the equals signs, but the use of parentheses
Robert Haas wrote:
I could live with the equals signs, but the use of parentheses seems
weird and inconsistent with normal english usage (which permits
parentheses as a means of making parenthetical comments).
But it is consistent with people seeing:
Seq Scan on foo (cost=0.00..155.00
Itagaki Takahiro escreveu:
Here is an updated patch per discussion.
* Counters are accumulative. They contain I/Os by child nodes.
* Text format shows all counters.
* Add shared_ prefix to variables representing shared buffers/blocks.
Nice. Despite of the other opinions, I'm
Itagaki Takahiro escreveu:
The attached patch is rebased to current CVS.
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.
+Include information on the buffers.
Euler Taveira de Oliveira eu...@timbira.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
On Thu, Oct 15, 2009 at 3:29 AM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
In this case, I think that the auto_explain changes out to be part of
the same patch as the core EXPLAIN changes
Here is a rewritten patch to add EXPLAIN
Jeff Janes jeff.ja...@gmail.com wrote:
Just a quick note: this patch does not apply cleanly to HEAD due to
the subsequent removal from explain.c of the near-by lines:
Thanks for reporting.
The attached patch is rebased to current CVS.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software
Robert Haas robertmh...@gmail.com wrote:
In this case, I think that the auto_explain changes out to be part of
the same patch as the core EXPLAIN changes
Here is a rewritten patch to add EXPLAIN (ANALYZE, BUFFERS) and
support for it by contrib/auto_explain. I removed pg_stat_statements
On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
EXPLAIN BUFFERS only shows 'hit', 'read' and 'temp read' in text format
to fit in display, but xml or json format contains all of them.
I was very careful when I submitted the machine-readable explain patch
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
EXPLAIN BUFFERS only shows 'hit', 'read' and 'temp read' in text format
to fit in display, but xml or json format contains all of them.
I was very careful when I
On Thu, Oct 15, 2009 at 11:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
EXPLAIN BUFFERS only shows 'hit', 'read' and 'temp read' in text format
to fit in display, but
62 matches
Mail list logo
