Re: [GENERAL] Weirdness with the stats collector process

2016-07-26 Thread Tom Lane
Matthew Musgrove writes: > I asked what network changes were made on July 7th around 14:05 and was told > that they disabled IPv6! I had them turn it back on and stats started working > immediately. Ooops ... > I have since changed the config from listen_addresses = '*' to > listen_addresses

Re: [GENERAL] Weirdness with the stats collector process

2016-07-26 Thread Matthew Musgrove
On 07/25/2016 03:20 PM, Tom Lane wrote: Matthew Musgrove writes: One of our instances has been behaving -- oddly. Most queries are blazing fast. It appears to just be some of the stat views that are slow. It sounds like requests for stats updates are no

Re: [GENERAL] Weirdness with the stats collector process

2016-07-25 Thread Adrian Klaver
On 07/25/2016 11:50 AM, Matthew Musgrove wrote: One of our instances has been behaving -- oddly. Most queries are blazing fast. It appears to just be some of the stat views that are slow. Does anyone have any suggestions on how to: - see what the statistics collector is doing? - tell the p

Re: [GENERAL] Weirdness with the stats collector process

2016-07-25 Thread Tom Lane
Matthew Musgrove writes: > One of our instances has been behaving -- oddly. Most queries are blazing > fast. It appears to just be some of the stat views that are slow. It sounds like requests for stats updates are not getting through to the collector. I wonder if your kernel is blocking those

[GENERAL] Weirdness with the stats collector process

2016-07-25 Thread Matthew Musgrove
One of our instances has been behaving -- oddly. Most queries are blazing fast. It appears to just be some of the stat views that are slow. Queries against the following views are quick: pg_stat_activity, pg_stat_xact_all_tables, pg_stat_xact_sys_tables, pg_stat_xact_user_tables, pg_statio_sys_