| 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: | Whole Thread | Raw Message | 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 |