From: | Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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 12:22:47 |
Message-ID: | 482AD997.7070307@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Luis Vargas | 2008-05-14 13:50:58 | Re: Execution Plan Cost |
Previous Message | Andrew Dunstan | 2008-05-14 12:18:30 | Re: libpq object hooks |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-14 14:22:02 | Re: [PATCHES] stored procedure stats in collector |
Previous Message | Andrew Dunstan | 2008-05-14 12:18:30 | Re: libpq object hooks |