Lukas Fittl

Ah, that's actually an important detail to know: The two helper functions mentioned (`get_stat_replication` and `get_column_stats`) are both recommended **even** when you have assigned `pg_monitor` to the pganalyze user. The...

@joekohlsdorf Thanks for bringing this up! The challenge here is that doing the data fetching at different random intervals would cause the statistics to be subtly different, potentially causing surprising...

Ah, thanks for the clarification. We were discussed this a bit more internally, and we're still not sure if a change like this wouldn't end up causing unexpected problems (e.g....

@joekohlsdorf Makes sense, thanks for clarification re: overall CPU usage being low. I think over time we do want to evolve the scheduling approach, but currently the trade-off here (i.e....

@jaxn Currently this is out of scope, mostly because it would take some effort, and hasn't been requested much. Is there a particular issue you're running into with your tests?

@metdos Thanks for reporting - did you get any errors on the Postgres side, in the Rails output, or in the Javascript debug console in your browser?

@Hubbitus We ended up not using pg_stat_plans due to https://github.com/2ndQuadrant/pg_stat_plans/issues/39

@ringerc @tvondra Minor note: If you invest resources into pg_stat_plans again (which is a great extension!), please consider fixing/investigating https://github.com/2ndQuadrant/pg_stat_plans/issues/39 Its dangerous to publicize this extension otherwise.

@simonat2ndQuadrant I unfortunately don't have one - we abandoned pg_stat_plans for pg_stat_statements back in 2014 due to this issue. Unfortunately I neither have the resources nor the know-how to fix...

@PhilipTrauner Thanks for the contribution! A few preliminary thoughts: - Whilst I can see how the separate shell script makes it easier, the fact that one can't use `make`, but...