Re: stats_block_level

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: stats_block_level
Дата
Msg-id 200707270333.l6R3Xa008320@momjian.us
обсуждение исходный текст
Ответ на Re: stats_block_level  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

Agreed.  Jan had a tendency to add more GUCs than needed "just in case",
but usually "case" never happened.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: LSN grouping within clog pages
Следующее
От: Satoshi Nagayasu
Дата:
Сообщение: Re: stats_block_level