On Tue, Feb 16, 2010 at 3:54 PM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 number of blocks too.
Greg Stark escribió:
> On Tue, Feb 16, 2010 at 2:48 AM, Robert Haas 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 longer
> > accur
On Tue, Feb 16, 2010 at 2:48 AM, Robert Haas 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 which case it represen
On Mon, Feb 15, 2010 at 6:44 PM, Greg Stark 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 sense of.
We
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 e
On Mon, Feb 15, 2010 at 7:58 PM, Robert Haas 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 informati
On Mon, Feb 15, 2010 at 1:29 PM, Greg Stark wrote:
> On Mon, Feb 15, 2010 at 6:05 PM, Robert Haas 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 wa
On Mon, Feb 15, 2010 at 6:05 PM, Robert Haas 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 in memory units
On Mon, Feb 15, 2010 at 9:55 AM, Greg Stark wrote:
> On Mon, Feb 15, 2010 at 2:22 PM, Robert Haas 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".
>>>
>
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
for
On Mon, Feb 15, 2010 at 2:22 PM, Robert Haas 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 signi
On Sun, Feb 14, 2010 at 8:25 PM, Greg Stark 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 botto
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 h
On Sun, Dec 13, 2009 at 11:49 PM, Takahiro Itagaki
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
Takahiro Itagaki writes:
> Tom Lane 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
> not be a performance overhead because the c
On Sun, Dec 13, 2009 at 11:49 PM, Takahiro Itagaki
wrote:
>
> Robert Haas 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
Robert Haas 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 patch adds INSTRUME
On Sun, Dec 13, 2009 at 10:00 PM, Takahiro Itagaki
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?
>
> I think the overflo
On Sun, Dec 13, 2009 at 10:15 PM, Tom Lane wrote:
> Takahiro Itagaki 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
Tom Lane wrote:
> Takahiro Itagaki 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
Takahiro Itagaki 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 ...
overhead that would be paid
Robert Haas 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 function doesn't
>
On Sun, Dec 13, 2009 at 7:55 PM, Takahiro Itagaki
wrote:
>
> Robert Haas 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 t
Robert Haas 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 explain_ExecutorEnd() had been change
On Fri, Dec 11, 2009 at 11:36 AM, Euler Taveira de Oliveira
wrote:
> Robert Haas escreveu:
>> On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
>> wrote:
>>> Anyway, a revised patch according to the comments is attached.
>>> The new text format is:
>>> Buffers: shared hit=675 read=968, temp read
Robert Haas escreveu:
> On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
> 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
On Thu, Dec 10, 2009 at 9:35 PM, Takahiro Itagaki
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 have zero values.)
> * Ren
Robert Haas wrote:
> On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith 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
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
> e
On Thu, Dec 10, 2009 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
>> 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
On Thu, Dec 10, 2009 at 10:52 AM, Greg Smith 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 "blocks" g
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 a
Robert Haas writes:
> On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
> 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 log_statement_stats (that was not I
On Thu, Dec 10, 2009 at 10:44 AM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 that specifies number
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
> --
On Thu, Dec 10, 2009 at 9:03 AM, Euler Taveira de Oliveira
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 get stats
>
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 Wed, Dec 9, 2009 at 12:36 AM, Takahiro Itagaki
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 lines in sgml.
> http://dev
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
Greg Smith 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 CF app, labeled as
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 suggest
On Dec 8, 2009, at 12:05 AM, Greg Smith 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 consistent with people see
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 s
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 rows=1000
Robert Haas wrote:
> On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith 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 seems
> weird and inconsistent with nor
On Mon, Dec 7, 2009 at 11:09 PM, Greg Smith wrote:
> Robert Haas wrote:
>
> On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
> 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) Lo
Robert Haas wrote:
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
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
written=0) Temp Blocks: (read=1443 wr
On Mon, Dec 7, 2009 at 9:58 PM, Itagaki Takahiro
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 buffers/blocks.
>
> Euler Taveira d
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 wrote:
> Itagaki Takahiro escreveu:
> > I think the c
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
on
On Mon, Dec 7, 2009 at 1:28 AM, Itagaki Takahiro
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 object
Euler Taveira de Oliveira 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
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. Specificall
Jeff Janes 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 Center
explain_bu
On Thu, Oct 15, 2009 at 3:29 AM, Itagaki Takahiro
wrote:
>
> Robert Haas 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/
On Thu, Oct 15, 2009 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
>> 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 c
Robert Haas writes:
> On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
> 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
On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
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
to make sure that the choice
60 matches
Mail list logo
