SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
05-16-2008, 01:43 PM
| ||||
| ||||
 Re: stored procedure stats in collector Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Tom Lane wrote: >>> 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 :-) > > Shouldn't we at least make it fail with EINVAL if "who" doesn't match > whichever semantics this code is able to implement? > > [ not relevant to the immediate patch, I suppose, but it might save some > tears later. ] Yeah, we only ever call it asking for our own process, but I guess we might at some point in the future change that, so it can't hurt.. Want me to do it, or will you? //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches      |
|
05-16-2008, 01:43 PM
| |||
| |||
| Re: stored procedure stats in collector Magnus Hagander <magnus@hagander.net> writes: > Tom Lane wrote: >> Shouldn't we at least make it fail with EINVAL if "who" doesn't match >> whichever semantics this code is able to implement? > Yeah, we only ever call it asking for our own process, but I guess we > might at some point in the future change that, so it can't hurt.. Want > me to do it, or will you? Please do, I'm going to bed ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches |
|
05-16-2008, 01:43 PM
| |||
| |||
| Re: stored procedure stats in collector Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> Tom Lane wrote: >>> Shouldn't we at least make it fail with EINVAL if "who" doesn't match >>> whichever semantics this code is able to implement? > >> Yeah, we only ever call it asking for our own process, but I guess we >> might at some point in the future change that, so it can't hurt.. Want >> me to do it, or will you? > > Please do, I'm going to bed ... Done. //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches |
|
05-16-2008, 01:43 PM
| |||
| |||
| Re: stored procedure stats in collector > What I think we should do about that is forget tracking getrusage()'s > user/system/real time and just track elapsed time. We have the > technology to get that in a portable fashion (cf the well-proven > instrument.c code). Such a decision would also alleviate two of the > biggest negatives of this patch, which are the runtime overhead and > the extent to which it's going to bloat the pgstats file. > I find the utime/stime quite useful, compared with the actual time it enables us to distinguish waiters (remote calls, sleeps, etc) from the actual CPU hogs. The difference is also very visible for IO bound functions. At least in our case it is a very useful tool for diagnosing performance issues and the overhead is not really visible. Perhaps the track_functions should just be set to none, or enabled selectively (session, function guc, user guc) for the environments where getrusage() is particularly expensive? Maybe a note in the docs that tracking is potentially expensive, and should be used carefully in production env. Regards, Martin -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches |
|
05-16-2008, 01:43 PM
| ||||
| ||||
| Re: stored procedure stats in collector Martin Pihlak <martin.pihlak@gmail.com> writes: > Now I just realized that the current patch doesn't handle this quite > correctly. Modified patch attached. Applied with revisions as per discussion. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches |
Linear Mode
