Tom,
>> Yes. It's pure overhead with no redeeming social value except to those
>> who actually want to look at that sort of stat, and those who do can
>> certainly turn it on for themselves.
I think the stats stuff should be on by default even if it causes
some performance penalty.
Because when we have performance problems on the production system,
it needs more performance penalty (about 5%~) to measure the stats
by turning their params on.
In real scenario, we always need the performance information,
so we always need to turn. So I want the performance information
can be taken by default.
Just my thought.
Tom Lane wrote:
> I wrote:
>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>> Anybody got any objection to setting it on by default?
>
>> Yes. It's pure overhead with no redeeming social value except to those
>> who actually want to look at that sort of stat, and those who do can
>> certainly turn it on for themselves.
>
> On second thought ... the cost of incrementing n_blocks_read etc is
> certainly negligible. The overhead comes from sending messages to the
> collector, having the collector maintain table entries, writing those
> entries out to a file, etc. And AFAICS all that overhead is expended
> per table: if you touch a relation during a transaction, the ensuing
> costs are identical no matter whether you have stats_block_level or
> stats_row_level or both turned on.
>
> Furthermore, it seems pretty likely that a transaction that creates any
> row-level counts for a table will also create block-level counts, and
> vice versa.
>
> So maybe the *real* question to ask is why we have separate GUCs for
> stats_row_level and stats_block_level. Shouldn't we fold them into a
> single switch? It's hard to see what having just one of them turned on
> will save.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
Phone: +81-50-5546-2496
