Re: stored procedure stats in collector

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, Volkan YAZICI <yazicivo(at)ttmail(dot)com>, pgsql-patches(at)postgresql(dot)org, postgres(at)cybertec(dot)at
Subject: Re: stored procedure stats in collector
Date: 2008-05-14 06:05:05
Message-ID: 13054.1210745105@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-05-14 06:07:54 Re: stored procedure stats in collector
Previous Message Magnus Hagander 2008-05-14 05:51:28 Re: stored procedure stats in collector

Browse pgsql-patches by date

  From Date Subject
Next Message Magnus Hagander 2008-05-14 06:07:54 Re: stored procedure stats in collector
Previous Message Magnus Hagander 2008-05-14 05:51:28 Re: stored procedure stats in collector