Re: Buffer statistics for pg_stat_statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Buffer statistics for pg_stat_statements
Date
Msg-id 22125.1262578359@sss.pgh.pa.us
Whole thread Raw
In response to Re: Buffer statistics for pg_stat_statements  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Buffer statistics for pg_stat_statements  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jan 3, 2010 at 10:17 PM, Takahiro Itagaki
> <itagaki.takahiro@oss.ntt.co.jp> wrote:
>> Robert Haas <robertmhaas@gmail.com> wrote:
>>> - There are needless whitespace changes in the definition of struct
>>> Counters. �The changes to the existing four members should be
>>> reverted, and the new members should be made to match the existing
>>> members.
>> 
>> That's because the 'shared_blks_written' field is too long to keep the
>> existing indentations. Since we still have some rooms in 80 columns,
>> I'd like to change all of them as the previous patch.

> I don't necessarily know what the right thing to do with the new ones
> is, but I am pretty sure that pg_indent will revert any changes you
> make to the existing ones.

That it will.  The proposed changes to the existing lines are an
exercise in uselessness; and to the extent that you format the added
lines with this layout in mind, the final result could be worse than
what you'd get if you adapt to pg_indent's rules to start with.

One possibility is to adopt shorter field names than these.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Next
From: Tom Lane
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns