Tom Lane wrote:
> 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.
True, but it works for this case :-)
>>> 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.
Agreed.
//Magnus
