Re: [HACKERS] memory fields from getrusage()

2017-09-01 Thread Justin Pryzby
On Sat, Sep 02, 2017 at 02:00:44PM +1200, Thomas Munro wrote: > On Sat, Sep 2, 2017 at 7:46 AM, Peter Eisentraut > wrote: > > On 6/15/17 10:58, Justin Pryzby wrote: > >> On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: > >>> On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby > >>> wrote:

Re: [HACKERS] memory fields from getrusage()

2017-09-01 Thread Thomas Munro
On Sat, Sep 2, 2017 at 7:46 AM, Peter Eisentraut wrote: > On 6/15/17 10:58, Justin Pryzby wrote: >> On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: >>> On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: > It mig

Re: [HACKERS] memory fields from getrusage()

2017-09-01 Thread Peter Eisentraut
On 6/15/17 10:58, Justin Pryzby wrote: > On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: >> On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: >>> On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: It might be worth adding platform-specific code for common platforms.

Re: [HACKERS] memory fields from getrusage()

2017-06-15 Thread Tom Lane
Justin Pryzby writes: > Comments ? I was wondering whether it'd be better to drive this off of configure probes for the existence of the struct fields. However, in view of the same fields having different contents on some platforms, such a probe wouldn't really help much --- you'd still need pla

Re: [HACKERS] memory fields from getrusage()

2017-06-15 Thread Justin Pryzby
On Thu, Jun 15, 2017 at 10:29:21AM -0400, Robert Haas wrote: > On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: > > On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: > >> It might be worth adding platform-specific code for common platforms. > > > > All I care (which linux happily/h

Re: [HACKERS] memory fields from getrusage()

2017-06-15 Thread Robert Haas
On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby wrote: > On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: >> It might be worth adding platform-specific code for common platforms. > > All I care (which linux happily/happens to support) is maxrss; I was probably > originally interested in

Re: [HACKERS] memory fields from getrusage()

2017-06-14 Thread Justin Pryzby
On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote: > It might be worth adding platform-specific code for common platforms. All I care (which linux happily/happens to support) is maxrss; I was probably originally interested in this while digging into an issue with hash agg. I think it's

Re: [HACKERS] memory fields from getrusage()

2017-06-13 Thread Robert Haas
On Sat, Jun 10, 2017 at 9:31 PM, Tom Lane wrote: > We already do call getrusage(). The point of that comment is that the > contents of the resulting struct rusage are not very well standardized. > POSIX says only > > The header defines the rusage structure that includes > at least the fo

Re: [HACKERS] memory fields from getrusage()

2017-06-10 Thread Tom Lane
Justin Pryzby writes: > This comment from ~1996 says: > https://doxygen.postgresql.org/postgres_8c_source.html > 4421 * the only stats we don't show here are for memory usage -- i can't > 4422 * figure out how to interpret the relevant fields in the rusage > struct, > 4423 * and

[HACKERS] memory fields from getrusage()

2017-06-10 Thread Justin Pryzby
I'm interested to expose output of the remaining (memory) fields from getrusage(). postgres=# SET log_parser_stats='on'; postgres=# SELECT c.oid::regclass, usagecount FROM pg_buffercache b JOIN pg_class c USING (relfilenode) WHERE usagecount=1 ; LOG: PARSER STATISTICS DETAIL: ! system usage st