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
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 |
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 |