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