Re: stored procedure stats in collector - Mailing list pgsql-patches

From Tom Lane
Subject Re: stored procedure stats in collector
Date
Msg-id 13054.1210745105@sss.pgh.pa.us
Whole thread Raw
In response to Re: stored procedure stats in collector  (Magnus Hagander <magnus@hagander.net>)
Responses Re: stored procedure stats in collector
List pgsql-patches
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> I found another fairly big problem, which is that this stuff isn't even
>> going to begin to compile on Windows.

> Where exactly is taht problem? In getrusage()? We have a getrusage() in
> src/port that works fine on Windows, no?

Huh ... I'd forgotten about that ... although it seems to work only for
rather small values of "work", since the WIN32 code path isn't paying
attention to the "who" argument.

>> What I think we should do about that is forget tracking getrusage()'s
>> user/system/real time and just track elapsed time.

> Those argument makes a lot of sense, though.

Yeah, the real bottom line here is whether we are buying anything that's
worth another two kernel calls per function.  Given all the buffering
and offloading of I/O to bgwriter that we try to do, it's hard to argue
that stime/utime measurements for the current backend really mean a lot.

            regards, tom lane

pgsql-patches by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: stored procedure stats in collector
Next
From: Magnus Hagander
Date:
Subject: Re: stored procedure stats in collector