From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | hlinnaka(at)iki(dot)fi, Radovan Jablonovsky <radovan(dot)jablonovsky(at)replicon(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: adding more information about process(es) cpu and memory usage |
Date: | 2015-04-24 01:28:52 |
Message-ID: | 31151.1429838932@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Thu, Apr 23, 2015 at 10:17 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)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. This could support a \timing feature
> variant to psql that reports more than just wall-clock time.
> I don't use RDS, and use shell access and "top" (and "strace" and "gdb")
> quite enthusiastically, but still it is a pain to correlate any given
> front-end to any given back-end.
> Would such an addition to core be welcome?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-04-24 01:52:27 | Re: a fast bloat measurement tool (was Re: Measuring relation free space) |
Previous Message | Jeff Janes | 2015-04-24 01:22:14 | Re: adding more information about process(es) cpu and memory usage |