On 6/22/15 8:05 PM, Robert Haas wrote:
>> In totally different crazy way we could just use the existing buffer
>> >manager we have and simply put the stats file in
>> >shared_buffers. Inventing a per-database relfilenode that doesn't
>> >conflict doesn't seem impossible. With some care it shouldn't be hard to
>> >make that stats file readable from all sessions, even if they're not
>> >connected to the database (e.g. autovacuum launcher).
> Interesting idea. We could consider the set of stats files a database
> unto itself and reserve a low-numbered OID for it. The obvious thing
> to do is use the database's OID as the relfilenode, but then how do
> you replace the stats file?
I think one of the biggest use cases for the stats is to collect them
over time and put them in a database. It's rather tempting to just say
that's what we should be doing, and provide a knob for how often to
record the values and how long to keep the data for. That would
eliminate a lot of these problems.
The one part I don't see how to solve is the case where bad stuff is
happening *right now* and you don't/can't wait for the next reporting
interval. Presumably handling that requires all the stuff that's
discussed already and you might as well just handle the recording in
user space. But maybe someone has some clever ideas there...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com