Le 24/04/2015 21:11, Jim Nasby a écrit :
On 4/24/15 6:29 AM, Robert Haas wrote:
On Thu, Apr 23, 2015 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason nobody's gotten around to that in the last fifteen years is
that per-process rusage isn't actually all that interesting; there's
too
On Thu, Apr 23, 2015 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason nobody's gotten around to that in the last fifteen years is
that per-process rusage isn't actually all that interesting; there's
too much that happens in background daemons, for instance.
There's *some* stuff that
On 4/24/15 6:29 AM, Robert Haas wrote:
On Thu, Apr 23, 2015 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason nobody's gotten around to that in the last fifteen years is
that per-process rusage isn't actually all that interesting; there's
too much that happens in background daemons, for
On 04/23/2015 08:00 PM, Radovan Jablonovsky wrote:
During current encounters with amazon web services - RDS, the DBA does not
have access to OS/linux shell of underlying instance. That render some
postgresql monitoring technique of process CPU and memory usage, not
useful. Even if the AWS
During current encounters with amazon web services - RDS, the DBA does not
have access to OS/linux shell of underlying instance. That render some
postgresql monitoring technique of process CPU and memory usage, not
useful. Even if the AWS provide internal tools/programming interface for
Jeff Janes jeff.ja...@gmail.com writes:
On Thu, Apr 23, 2015 at 10:17 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
In a nutshell, I don't think PostgreSQL should get involved in that...
I have often wanted an SQL function which would expose the back-end's
rusage statistics to the front-end.
On Thu, Apr 23, 2015 at 10:17 AM, Heikki Linnakangas hlinn...@iki.fi
wrote:
On 04/23/2015 08:00 PM, Radovan Jablonovsky wrote:
During current encounters with amazon web services - RDS, the DBA does not
have access to OS/linux shell of underlying instance. That render some
postgresql
