Re: stats_block_level - Mailing list pgsql-hackers

From Erik Jones
Subject Re: stats_block_level
Date
Msg-id 7163AD2A-8EA8-4465-8DD6-02E843163AEE@myemma.com
Whole thread Raw
In response to Re: stats_block_level  (Jim Nasby <decibel@decibel.org>)
Responses Re: stats_block_level  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Jul 27, 2007, at 6:45 PM, Jim Nasby wrote:

> On Jul 26, 2007, at 2:03 PM, Tom Lane wrote:
>> 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.
>
> IIRC, the guys at Emma have seen a performance difference with
> stats_block_level off and row_level on, presumable due in part to
> having 150k tables.
>
> Erik? Kim?

Well, we turned it off at the same time we moved from 8.2.3 to 8.2.4
so the actual culprit may have been what prompted the stats collector
improvement that went into that release.  I could test turning it
back on this week if you like -- I certainly would like to have my
blks_read/cach_hits stats back.  Toggling stats_block_level will
respond to a reload, yes?

Software Developer | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Quick idea for reducing VACUUM contention
Next
From: Andrew Dunstan
Date:
Subject: pipe chunking vs Windows