From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: stats_block_level |
Date: | 2007-07-26 21:03:37 |
Message-ID: | 2148.1185483817@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2007-07-26 21:39:55 | Re: stats_block_level |
Previous Message | Bruce Momjian | 2007-07-26 20:18:15 | Re: Updated tsearch documentation |