Re: Buffer statistics for pg_stat_statements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Cedric Villemain <cedric(dot)villemain(at)dalibo(dot)com>
Subject: Re: Buffer statistics for pg_stat_statements
Date: 2010-01-04 04:12:39
Message-ID: 22125.1262578359@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jan 3, 2010 at 10:17 PM, Takahiro Itagaki
> <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-04 04:18:26 Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Previous Message Robert Haas 2010-01-04 03:41:49 Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns