Re: stats_block_level - Mailing list pgsql-hackers

From Tom Lane
Subject Re: stats_block_level
Date
Msg-id 2148.1185483817@sss.pgh.pa.us
Whole thread Raw
In response to Re: stats_block_level  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: stats_block_level  (Dave Page <dpage@postgresql.org>)
Re: stats_block_level  (Bruce Momjian <bruce@momjian.us>)
Re: stats_block_level  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Re: stats_block_level  (Jim Nasby <decibel@decibel.org>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updated tsearch documentation
Next
From: Dave Page
Date:
Subject: Re: stats_block_level