Re: pg_stat_*_columns?
От | Jim Nasby |
---|---|
Тема | Re: pg_stat_*_columns? |
Дата | |
Msg-id | 5589B52E.5020204@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: pg_stat_*_columns? (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: