Re: adding more information about process(es) cpu and memory usage

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

In response to

Responses

Browse pgsql-hackers by date

  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