Re: stored procedure stats in collector

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:07:54
Message-ID: 482A81BA.10700@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-14 06:16:04 Re: stored procedure stats in collector
Previous Message Tom Lane 2008-05-14 06:05:05 Re: stored procedure stats in collector

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-05-14 06:16:04 Re: stored procedure stats in collector
Previous Message Tom Lane 2008-05-14 06:05:05 Re: stored procedure stats in collector