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 по дате отправления: