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
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 formatt
15 matches
Mail list logo
